vendicatorat_private wrote: > Stack Shield is a new tool that add protection form "stack > smashing" attacks at compile time without changing a line of > code. > The home page is http://www.angelfire.com/sk/stackshield > It is still in beta. The home page say "Stack Shield uses a more secure protection system than other tool like Immunix Stack Guard." The "detailed information" page says "under construction" but the TECHNICAL file that comes with the download explains that the defensive mechanism is to create a second stack especially for return addresses. Similar to StackGuard, Stack Shield hacks the prolog and epilog functions to implement the defense, but instead of the StackGuard mechanism of instrumenting the main stack, Stack Shield copies the return addresses to the secondary stack. Upon return, the hacked epilog compares the return address on the secondary stack to that on the main stack. If they match, the return proceeds normally, and if they don't match, Stack Shield patches the main stack with the (presumably safe) return address from the secondary stack. This would seem to protect against precisely the same class of attacks as StackGuard: those that use buffer overflows to corrupt the return address in an activation record. The response to attack is subtly differet: * StackGuard: assumes the program is hopelessly corrupted, syslog's the attack, and exits. This potentially converts a root exploit into a denial-of-service attack if the victim program is a persistent daemon, e.g. inetd or nfsd, which you can fix with a watch-dog that restarts needed daemons. * Stack Shield: patches the return address and carries on. If in fact the return address is the only thing the attacker changed, then Stack Shield offers the advantage of no DoS attack. However, this is rarely the case; the overflow has likely corrupted a lot of the program's state into some random state, and so it will exhibit random behavior, and probably crash. Perhaps I don't see your point. How is this more secure than StackGuard? On some other not-quite-security issues: * Compatability: o Stack Shield has a fixed size buffer for the secondary stack. Deeply recursive programs will bust this buffer. o Stack Shield does not yet appear to have done the work necessary to support PIC mode, so it is unlikely to work with shared libraries. o Stack Shield is an outboard post-processor. This would be a HUGE compatability advantage, except that it appears to be a post-processor for assembly source files. Thus, you still need to have source code for the program to be protected. You also have to extensively hack make files to insert Stack Shield in the middle of compiling each file. The path of .c -> .o -> executable becomes .c -> .s -> stack shield -> .o -> executable. From our experience re-building all of Red Hat Linux with StackGuard, you can trust me that this will become an issue :-) o In Stack Shield's advantage, Stack Shield will work with gdb, while StackGuard can only work with a specially hacked gdb that knows about the StackGuard activation record format. * Performance: Stack Shield does a copy to the secondary stack and an increment in the prolog, and a compare and decrement in the epilog. This is essentially similar to the workload imposed by StackGuard using the "Random Canary" defense, where we have an outboard table of 128 random numbers that are statically modulo-mapped to functions. StackGuard in "Terminator Canary" mode (where the "canary" word is -1 (EOF), CR, LF, and 0; the set of common string function terminators) is likely to be faster. Thanks, Crispin ----- Crispin Cowan, Research Assistant Professor of Computer Science, OGI NEW: Protect Your Linux Host with StackGuard'd Programs :FREE http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:59:47 PDT