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
