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>