Bugtraq mailing list archives
Re: PAX & the Future of buffer overflows ?
From: Crispin Cowan <crispin () WIREX COM>
Date: Thu, 2 Nov 2000 18:58:22 -0800
Tim Lawless wrote:
On Wed, 1 Nov 2000, Crispin Cowan wrote:Yes it is: if a single vulnerability can be exploited, despite a defense, by just re-working the attack, then the defense is an obscurity defense. The defense simply requires the attacker to use a particular (obscure) technique to perpetrat the attack.If I understand you properly, then it could be said that openwall is relying on security via obscurity, no? That being because openwall may be circumvented by a particular (obscure) technique?
Yes, the non-executable stack segment of Openwall is an obscurity defense (with all due respect to Solar; Openwall has other security features). It is a particularly effective obscurity defense, in that it imposes almost zero administrative and performance penalties on the defender, and imposes significant obscurity penalties on the attacker, but it is fundamentally an obscurity defense.
If I am correct in this could we not say with some degree of comfort that all security, as it exists today, is obscure?
No, that is an incorrect extrapolation. A technique is an obscurity defense IFF it stops "standard" attacks against a particular vulnerability, but that the same vulnerability can be exploited with a different attack technique. The defense fails to close the vulnerability, and merely "obscures" it by requiring convoluted attack techniques. Not all security defenses have this property.
The methodology they apply to a particular problem, buffer overflows and the injection of code, may work.
That depends on what you mean by "work." Ways to bypass the PAX (and non-executable stack) defenses are already known. No amount of effort in improving the implementation of these defenses will make them actually secure. Different techniques must be found to move them from obscurity to security. Yes, PAX will "work" in that there are exploits in current circulation that PAX will stop. No, it will not "work" in that those exploits can be re-tooled to bypass PAX, and there's nothing in the PAX implementation that can be changed to prevent that.
This depends on the strength of their implementation and the theory-work behind their implementation. Because they do not solve 'the big picture' does not mean the project is of only academic intrest.
Agreed. PAX is an effective script-kiddie defense. If you don't mind paying 10% overhead to defend against script kiddies, while still being vulnerable to potentially re-tooled attacks, then it is of practical interest.
By your earlier post, and again, your paper, it was pointed out quite well that there remains a significant portion of the buffer overflow problem that needs to be addressed. This may be addressed by another package, or by later work on PaX's package. Either way, if the implementation strength is there and the theory is sound, a complete solution to the problem may not be far off.
The implementation may be good (I presume; it sounds pretty neat to me) but the theory is not sound. A complete solution to buffer overflows will not involve non-executable data page techniques. It's a good interim solution for people with the right trade-offs, but an end-solution must be resistant to re-worked attacks, and non-executable data pages doesn't achieve that. Crispin -- Crispin Cowan, Ph.D. Chief Research Scientist, WireX Communications, Inc. http://wirex.com Free Hardened Linux Distribution: http://immunix.org
Current thread:
- PAX & the Future of buffer overflows ? Crispin Cowan (Nov 03)
- <Possible follow-ups>
- Re: PAX & the Future of buffer overflows ? Crispin Cowan (Nov 04)