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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:30 PDT