Maybe I'm missing something here, but I don't see it. While it is easy to use the "overwrite buffer and stomp on stack" method to execute code for programs written as so void foo(char* inputdata) { char blah[X]; write_to_buffer_without_knowing_length(inputdata, blah); } How would you do it for a program rewritten as void foo(char* intputdata) { char* blah; blah=PMalloc(X); write_to_buffer_without_knowing_length(inputdata, blah); } Where PMalloc acts like malloc, but from a separate heap. Two other conditions further hold. All variables in this separate heap are viewed as "tainted" since they came from user input, and can not be used as arguments to system(), popen(), fopen(), etc. Given this, I don't see how it is possible to cause code to be executed. For one thing, you can't modify the stack. Secondly, since buffers can't be used as arguments for i/o calls, overwriting nearby buffers like char *program_path = "auxillary_program" to "/bin/csh" won't do you any good. (note: a pointer variable should never point to data on the stack anyway. I'm glad Java eliminated stack data. Pointers to stack data are the source of numerous bugs in C. There is a minor performance gain to having the compiler generate the stack allocation rather than call malloc(), but it's not worth it. Stack data has the benefit that it is automatically deallocated upon function return. My answer is to simply use C++ to achieve this with dynamically allocated resources) I for one, never use scanf(), gets(), or anything that doesn't know the size of the destination storage. It's plain stupid. I was tutoring a student today who had allocated a 20-byte buffer on the stack and used scanf to ask for a filename. Sheesh. One thing that should set off alarm bells immediately whenever your coding is a fixed size buffer justified with the idea "no one could ever use more than Y resources." Yeah, no one could ever use more than 11 character file names. 640K ram. 32-bit IP address space. etc, etc. If not for security, then for simple future flexability. -Ray