Message-ID: <3F4192BF.21566.118495BE@localhost>
Date: Tue, 19 Aug 2003 03:00:15 +0200
From: pageexec@...email.hu
To: bugtraq@...urityfocus.com
Subject: Re: Buffer overflow prevention


> In essence, PAX attempts a best-effort of mapping existing and unchanged
> Linux binaries (except for marking) so that they are mapped best for
> security.  They do this by changing almost only kernel code.

This is not correct. PaX is about researching various ways of protection
against memory corruption bugs. The kernel land approach has just happened
to be the first step, it does not mean it's the last one. And indeed, ever
since we introduced full ASLR (more than 2 years ago), PaX has extended
its reach into userland, since to make proper use of this, you have to
create so called ET_DYN executables (a userland change, available in both
Adamantix [1] and Hardened Gentoo [2] these days), and of course our
userland changes do not stop here, as you can see it in the future plan
documentation [3].

> W^X does not do what PAX does; rather, W^X attempts to solve many of
> the same problem AREAS, but using entirely DIFFERENT SOLUTIONS.

One of the PaX features ([4]) implements the least privilege policy
in the context of runtime code generation (which is one of the possible
ways to exploit a memory corruption bug). This is achieved by
separating writable and executable pages into distinct sets (and
keeping them that way, at least by default because we believe in
'secure by default'). To be able to do this separation you have to
have the ability to mark pages non-executable of course (writability
is not a problem). Now tell me how this is different from W^X which,
err, also implements non-executable pages (for the same purpose, no
less)?

> Yet, persistantly we have been flooded by PAX supporters demanding
> that we should give credit to the PAX people for the ideas in W^X.
> When we had NOT known about PAX, and when W^X does NOT technically do
> what PAX does.

You keep stating that you had not known about PaX yet when asked for
presenting the internal discussions you had while developing your
W^X and other solutions ([5]), you suddenly go silent? Do you want to
tell me that there are no mailing list archives, icb logs, etc about
your technical discussions? Or are they secret?

> Holy cow, can you guys please stop crowing for me to revise history!

In order to revise history, one would need to know it in the first
place.

> It is clear that W^X was developed without knowlege of PAX; it is clear
> that this is a case of two solutions to a similar problem space -- call it
> convergent evolution; it is clear that begging for credit is just making
> your efforts look more and more political and less and less techical.

> I urge the PAX authors to get their community's rabid foaming under control.

I see you have the habit of creating paper tigers then burning them hard
and then thinking you're the hero of the jungle. The fact is, there is no
such thing as 'our community with rabid foaming'. We're not OpenBSD after
all, so there's noone to control.

> In attack after attack posted to our mailing lists, we were not being asked
> to say that the ideas from the PAX people predated the ideas in W^X.  No, no!
> We were being told to say that W^X ideas were *COPIED* from PAX, when
> we had no idea that such a thing as PAX even existed!

Interesting, this [5] says otherwise, where did you pull that out of,
another paper tiger of yours?

> Furthermore, there are difference in approach between W^X and PAX which
> are so fundamental that it is clear we did not copy from PAX!

I don't think anyone was questioning the origin of your *code* since
there's next to no way to share such between Linux and the BSDs (at
least not in the VM).

> Like, our idea that mprotect should still permit a user to request a
> page that is PROT_EXEC|PROT_WRITE; by default the PAX people prefer to
> deny such requests.

We chose that because that's the more secure way. You allow runtime
code generation because there's maybe 0.1% of all applications that
need it and at the same time compromise the security measures you want
to provide as has been pointed out earlier in this thread (return-to-libc
style attack to call mprotect() and others). I personally believe that
it's better to have the best security out of the box for stuff like
sshd or apache, and live with the inconvenience of having to exempt
java explicitly.

> If you look at the PAX web and other much more formal documentation,
> you will find that they do not mention W^X.

For this there is a simple explanation: i have yet to finish the
documentation on related work (it will be a separate document),
it's a big undertaking when you consider the almost 40 references
i dug up on the net (some of which have apparently been unknown
even to researchers in this area well), so i chose to write code
instead. But rest assured, once it's finished, your work will be
a part of it as well (at the then current level of course, not long
forgotten and obsolete history as it happens in some papers).

> If you look at Crispin's StackGuard papers, you will not find a
> mention of ProPolice -- which is clearly a better StackGuard.  Why
> should we mention PAX?  It does not influence what OpenBSD users
> encounter.  Are Linux people being specifically told "This is PAX,
> like W^X in OpenBSD"?

Indeed, it's not about influencing others but simple courtesy of
acknowledging related work - something you have failed to do, or
when you did, you made misleading statements (think of your earlier
POSIX (non-)compliance claims in PaX which i see you stopped now).

> W^X was invented because we saw the need for it.  We had no idea
> that anyone else was working in the same area.

Actually i don't think this is something you should be so proud of,
it means that despite your claim ("Our aspiration is to be NUMBER ONE
in the industry for security") you didn't actually follow the industry
and have missed out on certain developments for years.

> I have seen about 50 mails from PAX developers or PAX-associated
> developers or users insisting that we say that W^X is a PAX derivative.

Please provide the references to these 50 emails from me or 'associated'
people.

> I will not revise history to make your ego feel less bruised.

There is no need to revise history, just make it known/available to
all.

[1] http://adamantix.org/
[2] http://www.gentoo.org/proj/en/hardened/
[3] http://pageexec.virtualave.net/docs/pax-future.txt
[4] http://pageexec.virtualave.net/docs/noexec.txt
[5] http://marc.theaimsgroup.com/?l=openbsd-misc&m=105060386219963&w=2

Powered by blists - more mailing lists