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>