Tobias Haustein wrote: > * Crispin Cowan (crispinat_private) [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/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:01:02 PDT