[EMAIL PROTECTED] 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/
