OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Crispin Cowan (crispinwirex.com)
Date: Thu Mar 28 2002 - 15:45:33 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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