Vincent wrote: >As computer science students, a friend and I have just ended a study on buffer >overflows and the existing protections a Linux system may use against them. > >This study deals with the various kinds of overflows (heap, stack) to >understand how they work and how they may be used to execute malicious code; >then it focuses on a few Linux solutions (Grsecurity features, Libsafe...), >and explains how they behave, which kinds of exploits they prevent >respectively... > Readers may also be interested in a similar paper that we published in 2000. It appeared at the DARPA DISCEX conference <http://schafercorp-ballston.com/discex/> , and again as an invited talk at the SANS 2000 conference <http://www.sans.org/sans2000/sans2000.htm> . You can read the paper here <http://immunix.org/StackGuard/discex00.pdf> The similarities are substantial: we also categorized the attack space (kinds of buffer overflows), surveyed the defenses, and considered optimal combinations of defenses to get good coverage at reasonable cost. Differences: * Our survey was much broader. We covered: * Non-executable buffers (i.e. Solar Designer's non-executable stack patch, and a similar feature in Solaris) * Array bunds checking (Compaq's ccc compiler, and the bounds checking GCC built by Jones & Kelly and maintained by Herman ten Brugge, Purify, and type safe languages such as Java) * Code pointer integrity checking (StackGuard, and the hand-coded stack introspection that Snarskii built into FreeBSD's libc) * We did not cover: * libsafe: it did not exist at the time * grsecurity: it is just a derivative of Solar Designer's work * PAX: it did not exist at the time * Prelude: I don't understand how a general purpose host intrusion detection system bears on a survey of buffer overflows * Stack Shield: it is just a weak immitation of StackGuard, with no advantages, and substantial disadvantages * We came to a somewhat similar conclusion: that a combination of tools was the ideal defense. However, our preferred combo was StackGuard + Solar Designer's non-executable stack patch, which is what we actually ship in Immunix. * StackGuard offers the best resistance to "stack smashing" attacks * Non-executable stack segments offer substantial resistance to code injection (payload) * The two techniques are transparently compatible, and the combined performance overhead is nearly zero * As above, we did not consider PAX, but we would still not recomend it for most applications: the 10% macrobenchmark performance hit is pretty high. * We are mystified why Vincent et al recomend Stack Shield instead of StackGuard: Stack Shield offers no advantages (it is not more secure and it is not faster) and is much more problematic to deploy. * Libsafe vs. StackGuard or Stack Shield is a true decision: Libsafe is incompatible with compiler techniques that munge the call stack (and incompatible with -fno-frame-pointer) so you have to choose one or the other Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html
This archive was generated by hypermail 2b30 : Tue Apr 02 2002 - 14:31:20 PST