From owner-freebsd-chat Mon Feb 17 16:59:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA00185 for chat-outgoing; Mon, 17 Feb 1997 16:59:14 -0800 (PST) Received: from darkstar (dialin1.anlw.anl.gov [141.221.252.101]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA00174 for ; Mon, 17 Feb 1997 16:59:11 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id RAA02975; Mon, 17 Feb 1997 17:57:47 -0700 Date: Mon, 17 Feb 1997 17:57:46 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: "Jordan K. Hubbard" cc: freebsd-chat@freebsd.org Subject: Re: Countering stack overflow In-Reply-To: <28127.856224517@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 17 Feb 1997, Jordan K. Hubbard wrote: [snip] > This is a problem as old as programming, and to castigate the FreeBSD > team specifically for it is just silly. Sure, everyone knows about > the famous fingerd hole and the problem of stack overflow in general - > why do you think gets() started spewing out that obnoxious warning a > long time back? Knowing about a problem, like stack overflow or goto > abuse or improper indentation or any of a thousand different > programmer evils does NOT somehow automatically prevent such problems > from reoccuring in the future, and I don't care who the programmer is > or what the operating system under discussion might be - as long as > humans are doing the programming, all are vulnerable to a repetition > of history. > > Jordan Thanks for the history. I shouldn't have castigated FreeBSD as if this were the only unix variant vulnerable, but since the all of the source code is available, this increases the need for defensive countermeasures. I think most people, when the stack overflow problem is first explained to them, are quite astounded. I am no exception here. 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. Charles Mott P.S. I think that Jordan is getting angry less often now that the position of President has been eliminated. He is losing the habits of a General Secretary.