From:	 Crispin Cowan <crispin@wirex.com>
To:	 bugtraq@securityfocus.com
Subject: Re: A buffer overflow study - generic protections
Date:	 Tue, 02 Apr 2002 14:02:15 -0800

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