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.
As I said in the post Stack Shield is in beta. Future versions
will contain a comparsion between the RET in the main
stack and the RET in the secondary stack. To avoid
performance decay where this is not required this will be
added as a command line option.
Perhaps I don't see your point. How is this more secure than StackGuard?
StackGuard protection system has an extremaly grave bug
with the terminator and null canaries. In certain circumstances (not rare) this bug
can be exploited
preventing StackGuard to detect stack corruption. I'm not
the autor of this exploit howewer, so I will not post it without
his autorization.
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.
As I stated in the TECNICAL file future relases of Stack
Shield will allow the user to specify the buffer size.
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.
To tell the truth currentely Stack Shield does not support it.
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 :-)
Stack Shield provides a front end for GCC and G++ to
automatize the compilation. So you have just to each occourrence of "gcc" or "g++"
with "shieldgcc" or "shieldg++" respectively.Also in future versions a front end for
make will added.
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.
As I said before terminator and null canaries can be exploited.
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/
Vendicator
P.S. Excuse me for my long quoting and for my English.
