Message-ID: <20040327112256.GA10031@devbox.adamantix.org>
From: peter at devbox.adamantix.org (Peter Busser)
Subject: Talk in #grsecurity

Hi!

> > Spender sent me the alleged exploit for exec-shield... and it bypasses the
> > protections offered by exec-shield completely without the need for brute
> > forcing.
> Does it actually bypass a protection that exec-shield claims to give, or
> is it doing something that exec-shield doesn't claim to be able to stop?

I think we are talking about real bugs here. Exec-shield has had real bugs
before. One of them was uncovered after a bug in PaXtest was fixed. (And I
mean a real bug here, not the weaknesses in the exec-shield design.) There
are other problems that some people know about.

> There's no love lost between the pax and exec-shield crews:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107209069402935&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107209256604442&w=2
>
> So I'd evaluate very carefully any claim made by either crew. It's possible
> that there is a real hole in exec-shield.  It's also possible that the
> "exploit" is simply doing stuff that exec-shield won't stop by design -
> remember that a design *goal* of exec-shield was to not be as kernel-intrusive
> as pax, so it would have a smaller footprint and be less likely to break stuff
> unintentionally.

If you start to evalute very carefully, you might as well take into account the
motivation behind the things that people say.

All PaX users and developers (I'm a PaX user myself BTW, not involved in
development and never have been) I talk to do this stuff in their free time.
That is, they do it for fun. There is no financial interest behind PaX. And
its quality is what ``sells'' PaX. (That is also the reason why it is used in
Adamantix. If there was something better than PaX, I would put that in
Adamantix instead.)

So far, my experience is that the people who are vocal about exec-shield are
employed by one company. This company payed for the development of exec-shield
and therefore has a direct financial interest in marketing their product. And
this marketing made things dirty.

Anyone who looks at the previous PaX vs. something else flamewars, will see that
they typically started as a reaction of individuals in the PaX community
against false claims and half-truths. What I hear from PaX users and developers
in private conversations, is that most of them could not care less what other
people use. They are happy with PaX and that is what counts. 

What they dislike however, is the never ending marketing crap where people
claim that their patch is (almost) as good as PaX and that it has less problems
than PaX. Personally, I dislike the way these anti-PaX people question my
integrity and the integrity of PaXtest. PaXtest was used in the past to
``prove'' that exec-shield was (almost) as good as PaX. These people were happy
with PaXtest and promoting it.

In the meantime PaXtest has evolved to show the design decisions that result
in security weaknesses in OpenBSD and exec-shield. Now everyone can easilly find
out the truth about these products, they try to kill the messenger. First by
telling people that I cannot be trusted (even though people who know me know
that integrity is very important to me). And second by telling people that
PaXtest is rigged and therefore cannot be trusted. Third by telling people to
cripple PaXtest by removing the things that show the design decisions in their
product. People aren't supposed to find about these weaknesses it seems. (BTW,
I added comments in the code to facilitate these people.)

You can configure PaX in such a way that it behaves much like exec-shield. But
with equally lower security of course. So the compatibility issue between PaX
and exec-shield is not as big as some people want us to believe. At least you
can make your own choice between compatibility and security.

The biggest advantage of exec-shield over PaX is that PaX halves the address
space. Instead of the usual 3G address space, you get only 1.5G. So far I have
never heard anyone complain about that, therefore I believe that it is not a
big issue. For a number of corporate applications, I can understand why it is
a big problem. I think that for applications like that, going 64 bit would be a
more logical solution. BTW, this is a documented feature, just like all PaX
features are documented (see: http://pax.grsecurity.net/docs/).

The biggest advantages of PaX over exec-shield are that PaX supports many
architectures. And it can provide perfect protection against ALL attacks where
arbitrary code is injected and executed. No other kernel patch is able to
provide a similar protection level. That's the truth.

Groetjes,
Peter Busser

Powered by blists - more mailing lists