Re: A buffer overflow study - generic protections

[Crispin Cowan <crispin () wirex com>]

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