[7542] in bugtraq
Re: A way to prevent buffer overflow exploits? (was: "Any user can
daemon@ATHENA.MIT.EDU (Crispin Cowan)
Thu Aug 6 12:55:28 1998
Date: Wed, 5 Aug 1998 11:38:07 -0700
Reply-To: Crispin Cowan <crispin@CSE.OGI.EDU>
From: Crispin Cowan <crispin@CSE.OGI.EDU>
X-To: Richard Kettlewell <rjk@GREENEND.ORG.UK>
To: BUGTRAQ@NETSPACE.ORG
Richard Kettlewell wrote:
> 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 idea of randomizing the stack was put forward by Stephanie Forrest et al in
their HotOS'97 paper "Building Diverse Computer Systems". They proposed to add
a random amount fo fill to each activation record, so that the return address
was an unknown offset from the buffers being overflowed. It's cute, but it
doesn't prevent the attacker from just repeating the desired destination
address over and over again, reducing the problem to one of hitting the correct
byte allignment. Aleph One describes techniques to overcome problems like this
in his Phrack 49 paper "Smashing the Stack for Fun and Profit." One
interesting technique if you can inject a LOT of data is to put a few thousand
NOPs ahead of your attack code: then you only have to lob the return address
to point somewhere in the middle of the field of NOPs, and execution will just
flow down into your attack code.
> 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).
The catch here is that the attacker does NOT have to inject the attack code
into the same buffer used to smash the return address. They could inject the
attack code into ANY buffer, including statically allocated buffers. Or they
could point to code that already exists in the program, after creatively
setting up registers for a system call. Such an attack (which defeats Solar
Designer's non-executable stack patch) was posted to Bugtraq in June
http://www.geek-girl.com/bugtraq/1998_2/0651.html
> 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.
I like it. It's more effective that Forrest's apprach, and its cheaper.
It is also faster than the StackGuard approach, but probably not as effective.
In particular, if the attacker uses the technique mentioned above, then they
don't have to point the return address at a fixed point within the stack.
StackGuard, on the other hand, will detect any buffer overflow that corrupts
the return address.
We are currently interested in adaptive security mechanisms. As such, we're
very interested in BOTH techniques that are faster and less secure than
StackGuard, as well as techniques that are slower and more secure than
StackGuard (i.e. array bounds checking). Naturally, something that is faster
and more effective than StackGuard would be very interesting, but would make me
personally less happy :-)
> 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.
I'd be very interested in continuation of this work. We have a collection of
stack smashing Linux exploits and associated vulnerable code, if you want to
use them for testing.
Crispin
-----
Crispin Cowan, Research Assistant Professor of Computer Science, OGI
StackGuard: protect your software against Stack Smashing Attack
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
Support Justice: Boycott Windows 98
