Date: Mon, 17 Feb 1997 19:43:09 -0800 From: David Greenman <dg@root.com> To: Charles Mott <cmott@srv.net> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, freebsd-chat@freebsd.org Subject: Re: Countering stack overflow Message-ID: <199702180343.TAA03412@root.com> In-Reply-To: Your message of "Mon, 17 Feb 1997 17:57:46 MST." <Pine.BSF.3.91.970217171614.2884C-100000@darkstar>
next in thread | previous in thread | raw e-mail | index | archive | help
>To summarize my view (which not everyone wants to hear), I think there are >two possible defenses which should be considered: > > (1) Randomly adjusting the initial value of the stack pointer when > a new process (not fork) is created. The adjustment range might > be between 0xr4fffffff and 0xffffffff. > > (2) A smart version of strcpy() which would try to guess whether it > is working on stack variable and try not to overrun the frame > pointer. It has been objected that the frame pointer is not > guaranteed, but I still think this concept, or a variant, bears > some looking at. > >Arguments against (1) are basically that it is not perfect, that there are >still viable attacks. Arguments against (2) [if it is actually feasible >-- I though I had seen a post from someone who had done something similar] >are that it adds instruction cycles and possibly makes the software less >reliable. My instincts tell me these arguments are not strong. > >I don't actually care too much about naysayers (and those who make unkind >comments in private e-mail). I'm not asking anyone to do any work -- I >like doing my own programming. I am just trying understand more about the >problem. I really don't see how any of this is going to affect the problem. You can use relative addressing/position independant code to get around any differences in stack addresses. The idea of putting guard pages* in the stack doesn't buy much, either, since one can still seriously affect the operation of a program by being able to change only local variables (pointers, loop variables, etc, etc). It makes the exploit somewhat more complex, but certainly not outside the ability of the people doing these attacks. As for frame pointer checks, adding something like that would simply break applications that expect to be able to access the stack variables of the caller (&local_variable to a sub function). In any case, I think people will be lulled into a false sense of security with such "fixes" for the stack overflow exploits. The only fixes that actually _work_ are the ones we are doing (e.g. using limited copy functions like strncpy and strncat, etc.). *) It's actually impossible to have sparse unmapped stack pages in the current architecture of the kernel. One of the many reasons is that there is no API for doing such creative things with the stack...and adding one would not only make applications *extremely* slow for doing procedure calls, but it would also dramtically increase the complexity of dynamic stack growth management in the kernel. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702180343.TAA03412>