Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Feb 1997 23:14:33 +0100
From:      roberto@keltia.freenix.fr (Ollivier Robert)
To:        freebsd-security@FreeBSD.ORG
Subject:   Re: buffer overruns
Message-ID:  <19970209231433.QS19404@keltia.freenix.fr>
In-Reply-To: <Pine.LNX.3.91.970209124900.2336B-100000@freon.republic.k12.mo.us>; from Richard Holland on Feb 9, 1997 12:57:33 -0600
References:  <Pine.BSF.3.91.970209111131.2503B-100000@www.trifecta.com> <Pine.LNX.3.91.970209124900.2336B-100000@freon.republic.k12.mo.us>

next in thread | previous in thread | raw e-mail | index | archive | help
According to Richard Holland:
> If I am right here, How would you know just how far you have to go over 
> and what the characters need to be once you get thus far?  Of course I 
> could be totally wrong here.  Realize that I am just now covering 
> pointers in the book I am reading on C :)

Many of the buffer overruns comes from the fact that many "temporary"
buffers are allocated from the stack as automatic variables like this:

int foo (...)
{
    char tmp [100];

Now imagine tmp is filled with something like this:

    strcpy (tmp, getenv("SOME_VARIABLE"));

If you put enough characters in $SOME_VARIABLE, you could trash, the return
address that is usually just before the automatic variables...

Realize that the the standard entry instructions for many functions is

        pushl   %bp
        movl    %sp,%bp
        subl    NN,%sp      /* where NN is the space for automatic vars */

So the stack will look like this:

        return address before the call
        saved %bp
        ...
        automatic variables (NN bytes approx.)

So if you able to calculate how many bytes the automatic variables will
take and put enough data in tmp to overrun all variables *and* the return
address, you'll be able to change that return address, making it pointing
to a portion of code of *your* doing, like 
"setuid (0); exec ("/bin/sh");"

Most of the buffer overruns are just that, enough data to trash the stack
then the exploit code itself. The trick is to calculate offsets just to
make the saved %sp from the previous call point to your code.

The easiest way to close all this bugs is to make the stack non executable
(from a processor standpoint) but I'm not sure you can do it in Intel
processors.

PS: I'm not sure at all I got the ASM syntax right, I'm still thinking in
    MASM mode than in GAS mode (reversed operands and all that).

PPS: sometimes it pays off to have been an ASM programmer before a C one
     and to look at what the compiler outputs for a given code... :-)

PPPS: ok, it was ASM/370 then 68XXX before even playing with Intel.
-- 
Ollivier ROBERT    -=- The daemon is FREE! -=-    roberto@keltia.freenix.fr
  FreeBSD keltia.freenix.fr 3.0-CURRENT #39: Sun Feb  2 22:12:44 CET 1997



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970209231433.QS19404>