Bugtraq mailing list archives
Re: Buffer overflow prevention
From: Solar Designer <solar () openwall com>
Date: Fri, 15 Aug 2003 22:37:57 +0400
Hi, On Fri, Aug 15, 2003 at 11:10:31AM +0200, Peter Busser wrote:
you can have all of your stuff run with a non-executeable stack, thus making stack smashing impossible.A non-executable stack patch provides no protection.
I am tired of hearing people say both of these things. Neither is entirely correct (although the first one is worse). The facts are: - non-executable stack doesn't fix any vulnerabilities and doesn't make them non-exploitable, but - non-executable stack may provide a layer of protection, making certain vulnerabilities harder to exploit in the real world. Non-executable stack, unlike many more advanced hardening measures (which have similar properties, only being a "thicker" "layer of protection"), doesn't have a performance impact. This property, in my opinion, makes it reasonable to use even despite the fact that the added protection it brings is very limited. Whether to also use those "more advanced hardening measures" may be decided on a case by case basis.
It is easy to circumvent.
Most of the time, yes. Yet this may be an additional bit of work for an attacker (or exploit writer) and often lower reliability for the exploit code with remote attacks (a smaller percentage of automated attacks succeed).
A few years ago there was a discussion about getting the OpenWall non-exec stack patch into Linus' kernel tree and Linus refused. He showed that it was easy to circumvent this stuff.
Linus, for obvious reasons, didn't participate in or read all of the discussions of the topic occurring on public mailing lists. The particular attack approach he has pointed out (return-into-libc) was publicly discussed before that and I was first to post working exploits relying on this approach to Bugtraq more than a year before Linus' post (1997 vs. 1998). I've also included a workaround preventing some attacks of this nature at the same time (1997). Others have published even smarter attacks since then. BTW, I've never raised the question of the patch (not) getting into the official kernel tree, -- other people did. I feel that many over-estimate the importance of that patch (hack?) I did. I wish some of their interest in that stuff I've been doing in 1997 would move to other projects, including Openwall GNU/*/Linux (Owl) which is an entire OS distribution rather than just a kernel patch. -- Alexander Peslyak <solar () openwall com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments
Current thread:
- Re: Buffer overflow prevention, (continued)
- Re: Buffer overflow prevention Craig Pratt (Aug 13)
- Re: Buffer overflow prevention Patrick Dolan (Aug 13)
- Re: Buffer overflow prevention Mariusz Woloszyn (Aug 14)
- Re: Buffer overflow prevention Crispin Cowan (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- RE: Buffer overflow prevention Lance James (Aug 14)
- Re: Buffer overflow prevention Patrick Dolan (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Stephen Clowater (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Solar Designer (Aug 15)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Mariusz Woloszyn (Aug 14)
- Re: Buffer overflow prevention Theo de Raadt (Aug 14)
- Re: Buffer overflow prevention Matt D. Harris (Aug 14)
- Re: Buffer overflow prevention sauron (Aug 14)
- Re: Buffer overflow prevention Timo Sirainen (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Theo de Raadt (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Miod Vallat (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)