From owner-freebsd-chat Mon Feb 17 19:41:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA10536 for chat-outgoing; Mon, 17 Feb 1997 19:41:59 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA10529 for ; Mon, 17 Feb 1997 19:41:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id TAA03412; Mon, 17 Feb 1997 19:43:09 -0800 (PST) Message-Id: <199702180343.TAA03412@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Charles Mott cc: "Jordan K. Hubbard" , freebsd-chat@freebsd.org Subject: Re: Countering stack overflow In-reply-to: Your message of "Mon, 17 Feb 1997 17:57:46 MST." From: David Greenman Reply-To: dg@root.com Date: Mon, 17 Feb 1997 19:43:09 -0800 Sender: owner-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >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