1995-09-22 - Re: netscape bug

Header Data

From: Ray Cromwell <rjc@clark.net>
To: perry@piermont.com
Message Hash: ba6ec4b9e1f97daeaa30bb12bc28a0e5cc35bb2cf062c0c922b95fe4c5fc7ffd
Message ID: <199509220511.BAA00235@clark.net>
Reply To: <199509220443.AAA02254@frankenstein.piermont.com>
UTC Datetime: 1995-09-22 05:12:06 UTC
Raw Date: Thu, 21 Sep 95 22:12:06 PDT

Raw message

From: Ray Cromwell <rjc@clark.net>
Date: Thu, 21 Sep 95 22:12:06 PDT
To: perry@piermont.com
Subject: Re: netscape bug
In-Reply-To: <199509220443.AAA02254@frankenstein.piermont.com>
Message-ID: <199509220511.BAA00235@clark.net>
MIME-Version: 1.0
Content-Type: text/plain

  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;
  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.