>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/StackG>uard/

  Vendicator
P.S. Excuse me for my long quoting and for my English.

Reply via email to