On Wed, Aug 20, 2003 at 05:23:30PM +0200, Adam ENDRODI wrote:
> On Thu, Aug 14, 2003 at 12:00:40PM -0400, Matt Zimmerman wrote:
> > No, it really doesn't. It might stop some common implementations of
> > exploits, but that's about it. There are many papers available which
> > describe the shortcomings of this kind of prevention.
>
> Could you provide some pointers on the topic?
Google can provide enough. The general idea of stack protection is to
prevent common automated attacks from working. Given time and
determination, it is usually possible to circumvent it.
> > You don't need an executable stack to get control of execution, you only
> > need to be able to change the instruction pointer, which is stored on
> > the stack (as data).
>
> PaX is not just about non-executable address regions, but address space
> randomization. In my understanding, the attacker just doesn't know what
> he should modify the IP to. Given this, are you certain that only a
> narrow range of exploits ("common implementations") can be killed via PaX?
It is often the case that the attacker doesn't know the exact location of
structures in memory; there are techniques for finding out. I'm sure that
the authors of PaX do not misrepresent it as complete protection.
It's pointless to argue about it; it's clear that PaX provides some value in
protection against security vulnerabilities, and I think it's also clear
that because it will break many existing applications, it is not suitable
for use by default. But there is no reason why a PaX-enabled kernel could
not be provided as an option. All it needs is someone willing to do the
work (hint, hint).
--
- mdz
