Re: netscape bug

[Ray Cromwell <rjc@clark.net>]

  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