Re: PAX & the Future of buffer overflows ?

[Crispin Cowan <crispin () WIREX COM>]

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