[7529] in bugtraq
Re: A way to prevent buffer overflow exploits? (was: "Any user can
daemon@ATHENA.MIT.EDU (Richard Kettlewell)
Wed Aug 5 13:18:10 1998
Date: Wed, 5 Aug 1998 00:16:34 +0100
Reply-To: Richard Kettlewell <rjk@GREENEND.ORG.UK>
From: Richard Kettlewell <rjk@GREENEND.ORG.UK>
To: BUGTRAQ@NETSPACE.ORG
[This is a very-slightly-modified repost of the article I've been
trying to get through since Friday.]
Brett Lymn <blymn@BAEA.COM.AU> writes:
> According to John D. Hardin:
>> Or how about automatically allocating space just for local strings? This
>> would take care of buffer overflows with minimal impact, wouldn't it?
>
> In some languages, notably C, the concept of a string is a slippery
> thing. This is what the debate regarding C/Modula2/Ada/anythingbutgoddamC
> was about.
Actually the idea of putting local variables "somewhere else" has come
up before. See:
http://www.geek-girl.com/bugtraq/1997_1/0052.html
There's some more discussion on the same theme there but it misses one
possible idea: randomizing the address of the stack.
The article referenced by the URL points out that in a stack smashing
attack the attacker has to overwrite the return address from a
function with the address of their exploit code (which presumably they
loaded into the buffer they are overrunning in the same operation).
If the program under attack can make it hard to know what the address
of the exploit code is then they can slow down the progress of any
attacker. One way to do this would be to choose a random location for
the stack every time you do an exec().
Then the attacker can't know that (for example...) Debian's build of
qpopper happens to have its input buffer at a particular address each
time it runs; they have to try at least millions of possible
addresses.
This works better with daemons run from inetd than standalone daemons,
as they do a new exec() for each run of the attack; the attacker can't
even rely on a particular guess having failed once to rule it out. It
also works well on a 64-bit machine, where the size of the search
space can be made much bigger.
But even on a 32-bit machine with a long-running daemon which has a
fixed but initially unknown stack location it should be possible to
force an attacker to make millions of guesses before succeeding.
I'd be interested to know whether people think this would work.
ADDENDUM: since my original attempt to post this message I've
experimented some more, and got relatively encouraging initial
results. See:
http://www.greenend.org.uk/rjk/random-stack.text
for a semi-formal write-up.
