Re: A buffer overflow study - generic protections
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
--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: