Re: Ray Cromwell: Another Netscape Bug (and possible security

[carl () hdshq com (Diego Zamboni)]

At 10:32 AM 9/27/95 +0100, Leonard Krylov wrote:
> Hey folks, I need to know about this 'stack overwriting thing'
> thet is so lively discussed. As I understand it (and correct me
> if I'm wrong), the point is to pass in data to a non-bound
> checking routine (like syslog), and make it so constructed
> that it 'rewrites' some parameters on the stack.
> Subsequent routines will then pop these phoney params and
> off we go...
> Am I right? Can anybody provide me with more detailed info
> and perhaps some harmless example (please please please!!!)

Well - not exactly.

Automatic class variables are assigned locations on the stack when a
routine is invoked. There is also the return address of the calling routine
on the stack.

One of the automatic variables on the stack must be a string or array
variable for which the source copy does not do bound checking. In the case
of syslog, the code in syslog.c in the libc library does a sprintf into the
variable. If the string which is "printed" exceeds the allocated size of
the variable, the extra bytes are moved on top of other parts of the stack.
These are other automatic variables, and the return address and even
further on into the stack.

IF the data which is placed after the end of the automatic variable
consists of valid machine instructions, then when the syslog library
routine executes a return, it will execute the code sent by the malicious
user rather than return to the caller.

If the routine such as syslog was called by a process running with any
privileges such as root ID, then the potential for damage is high.

To exploit, you would need to know the relationship of the automatic
variable to all other variables on the stack, in order to locate the return
address area. You would need to know how to generate binary machine
instructions for the architecture of the machine under attack. You would
need to know enough about the run time environment (OS, release, etc) to
accomplish some evil intent. If all you want to do is add an entry to
/etc/passwd, this is pretty easy for a root ID process on any OS.

As you can see, an exploitation takes some research on the target (machine
architecture and OS), a service which takes some user provided information
and uses it on an automatic scope variable without bounds checking, and a
fairly sophisticated coder to produce the attack itself. More troubling
would be the provision of pre-engineered attack programs on BBS systems,
where the less clue-full could utilize them.

Sorry for not providing a sample, but to be able to evaluate such a machine
language and OS specific attack requires the same skills needed to generate
it. In this case, if you could not create the attack then looking at a
harmless sample would be of no benefit to you.

Hope I helped.


Carl V. Claunch                                        Hitachi Data Systems
Director of Technology                         MS 32-05
Open Systems Marketing                   750 Central Expressway
voice: 1-408-970-4301                         Santa Clara, CA  USA 95056
fax: 1-408-988-0651