Date: Mon, 17 Feb 1997 17:57:46 -0700 (MST) From: Charles Mott <cmott@srv.net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: freebsd-chat@freebsd.org Subject: Re: Countering stack overflow Message-ID: <Pine.BSF.3.91.970217171614.2884C-100000@darkstar> In-Reply-To: <28127.856224517@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970217171614.2884C-100000>