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