[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    Re: Stack Shield: defending from "stack smashing" attacks
From:       Crispin Cowan <crispin () CSE ! OGI ! EDU>
Date:       1999-08-31 17:13:21
[Download RAW message or body]

Tobias Haustein wrote:

> * Crispin Cowan (crispin@CSE.OGI.EDU) [990830 19:47]:

> >    * 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.
>
> During my tests, I found that my method produces an overhead in
> between of 7% and 13% in total execution time on most programs. As I
> recall your paper on StackGuard [1], your figures were somewhat
> larger, even though I would expect your method to be faster.

You can't really simplify StackGuard overhead to a single figure of merrit.
Microbenchmarks show that StackGuard adds 40% to 80% to the cost of a single
function call/return, but that is nowhere near representative of real
overhead.  Your real overhead results from the density of function calls
within your program.  We showed overheads in the 10% range in the USENIX
Security paper.  In our more recent Linux Expo 99 paper, we benchmarked
StackGuarded Apache, and showed virtually no measurable overhead.  Quick
run-down on the Apache experiment:

   * StackGuard-protected Apache running on linux
   * Linux client runs WebStone benchmark
   * both machines on a private 10 Mbit Ethernet

Yes, this test is largely dominated by I/O.  That's the point of the
experiment:  StackGuard protection for large network services does not
visibly add overhead.


> So, why would one use the approach of saving the return address on
> another stack, instead of patching the stack itself, like StackGuard?
> The only reason I can imagine, is that one does not want to change the
> stack layout. The benefit of not changing the stack layout, is that
> you can do the change outside of the compiler.

Another major advantage is that gdb continues to work.  The StackGuard method
fails for all programs that introspect the stack, gdb being the major
example.


> I was about to write a
> binary translator, that reads an executeable, locates every function
> prolog and epilog, adds the nescessary code to detect buffer
> overflows, and writes a new version of the executeable.

How do you make room for the extra code in prolog & epilog without re-linking
the entire program?


> Writing such a translator is possible, since there are examples of
> working tools that do similar things (Purify [2], Etch [3], ...).
> Anyway, doing this is a lot of work, therefore, I'm currently trying

That it's a lot of work to do binary translation is what motivated us to
implement StackGuard in the compiler :-)


> to find a skeleton for the translator, instead of writing one from
> scratch. If someone has a working translator on hand, I'm very
> interested in getting the source code to continue on this project.

A StackGuard-like tool that worked on binaries would in fact be a major
advantage, especially if it could work on stripped binaries (the kind you get
from closed-source vendors).  It would also be a LOT of work.

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/

[prev in list] [next in list] [prev in thread] [next in thread]