[OT] PaX
Theo de Raadt
Apparently you cannot keep to the facts.
> > For a start, PAX violates POSIX by breaking mprotect. By default, it
> > runs without ever permitting W | X to exist, which is wrong according
> > to standards
>
> http://www.opengroup.org/onlinepubs/007904975/functions/mprotect.html
>
> It's SUSv3, hopefully qualifies as a standard. Among others it says:
>
> -------------------------------------------------------------------
> If an implementation cannot support the combination of access types
> specified by prot, the call to mprotect() shall fail.
> -------------------------------------------------------------------
>
> OpenBSD couldn't support PROT_EXEC until 3.2 on any architecture,
False.
> and still cannot on some.
True.
> Therefore any mprotect() request not
> asking for PROT_EXEC shall fail, but they don't.
Shall? False.
> It's also clear
> that the standard anticipates implementations that are not able
> to provide all possible protection types so it's well within the
> spec to not provide them all, just make it clear to userland (by
> failing the offending mprotect() call - which PaX does).
You make it fail on all architectures, hence, False.
> Speaking of POSIX compliance, consider checking your own mmap()
> implementation for example. The spec says this:
>
> -----------------------------------------------------------
> The mmap() function shall fail if:
>
> [EACCES]
> The fildes argument is not open for read, regardless of the
> protection specified, or fildes is not open for write and
> PROT_WRITE was specified for a MAP_SHARED type mapping.
> -----------------------------------------------------------
>
> Compare this to your code in sys/uvm/uvm_mmap.c (notice the word
> 'regardless' above):
>
> ------------------------------------------------
> /* check read access */
> if (fp->f_flag & FREAD)
> maxprot |= VM_PROT_READ;
> else if (prot & PROT_READ) {
> error = EACCES;
> goto out;
> }
> ------------------------------------------------
>
> This i got after some 10 seconds of looking at it, feel free
> to check the rest of the code.
The above commentary is False.
> > expectations of software,
>
> That's when you modify non-compliant software to bring it in line
> with what the standard says.
False. You go too far.
> > and quite frankly unreasonable.
>
> Given our attack model, it's required. For details please see the
> docs at http://pageexec.virtualave.net/docs/ .
Given that you are more than happy to break programs that generate
native code inside their own images, False.
>
> > PAX is also utterly *GLACIAL* because of software tlb
> > loading, anyone want a 15% slowdown? It is not as interesting for us,
> > since it is not an OpenBSD-useable technology.
>
> I assume here that you're talking about the i386 support (since we last
> talked, we got PaX to work on alpha/parisc/ppc/sparc/sparc64). It may
> have missed your attention but on i386 PaX has two different non-exec
> implementations.
I know this.
> The one you're referring to above is called PAGEEXEC
> and is based on the paging logic. Its performance impact is not any
> fixed number, it can be anywhere between 0-500%, depending on mainly
> how good the given CPU's TLB is and the memory access pattern of a
> given application. The other approach is called SEGMEXEC and is based
> on the segmentation logic. Its performance impact i don't know exactly
> as i never tested it standalone,
Never tested? So people are using the slow one?
> only with other PaX features enabled,
> so the combined effect of randomization (ASLR as we call it) and this
> SEGMEXEC is around 1-2% on a kernel compilation 'benchmark' and that's
> because it does so many fork()/execve()/mmap(), otherwise the impact
> would be closer to 0%.
W^X on i386 and all our other architectures has zero slowdown. On some
architectures like sparc64 and powerpc, it actually sped the system up
because we can avoid I cache flushes.
> > W^X is not like no-exec stack. We had no-exec stack in our previous
> > release. Booooring. On any i386, anyone can craft their own frame
> > and return to libc without executing any of their own code. No-exec
> > stack is completely irrelevant without ProPolice, to canary protect
> > the return.
>
> There are bugs other than linear stack overflows which may still
> allow a return-to-libc style exploit (and in your case, totally
> circumvent W^X), what are you doing about them?
Nothing yet. W^X is a piece of the puzzle. Just as your "killing exec"
thing has nothing to do with this either.
> > Yes, other vendors who move to W^X are going to have to change their
> > binaries on some architectures. If they don't change, they might not
> > get these protections. That's a problem of most vendors using ELF
> > simply as if it was "a.out with ctor/dtor".
>
> PaX doesn't require changes in (most of) userland to provide all
> the protection features.
And ours does, so that we do not suffer performance like PAX.
> > PAX, as it is now breaking mprotect
>
> No, PaX does not break mprotect(), it does what the standard allows.
No, it breaks the standard and there are affected applications.
> Besides, if an app does need the relaxed behaviour, it can be allowed
> by simply setting an ELF header flag on the given binary.
By modifying the binary. So much for it being a kernel-only change!
> > and doing slow TLB handling,
>
> TLB handling is not slow in PaX per se,
False. Execute bit emulation in PAX is slow.
> it's the CPU/TLB architecture
> of IA-32 which makes things slower than necessary (i wish you succeeded
> in convincing the IA-32 vendors into adopting true hardware support for
> the non-exec flag).
I am having some success, talking with the right engineers at the
various companies. If you want me to keep trying, I suggest you stop
harassing us.
> Also PAGEEXEC is not even the default non-exec page
> implementation, it's SEGMEXEC.
>
> > will never be on by default in RedHat, but ProPolice and W^X are shipping
> > in OpenBSD. Again -- it will never ship on by default in RedHat --
> > anyone want to put money on a wager?
>
> PaX is already part of several distros, mostly because they use
> grsecurity. One can get it on Mandrake, Debian, Trusted Debian,
> Gentoo, etc.
And it is NOT ON BY DEFAULT! Can you not READ WHAT I SAID? I said
on by default in RedHat
Can't you read? Do you have some built-in desire to purposefully
misread what people say, just so that you can win your little
arguments? Does it make you feel like a big man?
> Besides, isn't it a bit unfair to compare the situation of PaX and
> RedHat to that of OpenBSD?
No, it is a bit unfair for people to say that what we've done in
OpenBSD should give credit to PAX. Considering we'd never heard of
PAX before we did W^X, and considering that our goal was to NOT BREAK
anything -- a goal you have NOT MET.
> You realize that you control everything
> (kernel+userland) in OpenBSD which is not true in our case.
Of course we do. And that allows us to NOT BREAK semantics.
> > We don't break anything that standards or defacto standards require.
>
> You do break POSIX as pointed out above.
False. Now go away.
page...@freemail.hu
At least this one we agree on ;-).
> Apparently you cannot keep to the facts.
Well, to be honest, you haven't been exactly forthcoming
with yours either whereas i did provide you with proper
online references to the standard i was talking about.
Where's yours?
> > OpenBSD couldn't support PROT_EXEC until 3.2 on any architecture,
>
> False.
On which arch did OpenBSD have proper PROT_EXEC semantics before 3.2
(all memory areas, not only stack)? I'm merely asking, i'll happily
give you this one and say 'most' instead of 'any'.
> > Therefore any mprotect() request not
> > asking for PROT_EXEC shall fail, but they don't.
>
> Shall? False.
Can't you read the standard? I've shown you the relevant excerpt,
if you think that's false, then tell us why.
> > It's also clear
> > that the standard anticipates implementations that are not able
> > to provide all possible protection types so it's well within the
> > spec to not provide them all, just make it clear to userland (by
> > failing the offending mprotect() call - which PaX does).
>
> You make it fail on all architectures, hence, False.
What is your logic in there? If i make mprotect() fail on not all
archs, it suddenly becomes acceptable? Besides, of course i ensure
that PaX has the same security features on all supported archs (well,
to the extent it's possible), hence the same behaviour of mprotect().
> > Speaking of POSIX compliance, consider checking your own mmap()
> > implementation for example. The spec says this:
[...]
> The above commentary is False.
Which part? The facts were taken from the standard and your own CVS
tree in case you haven't noticed, they can hardly be false. If you
think the standard doesn't cover your case, feel free to explain it.
> > That's when you modify non-compliant software to bring it in line
> > with what the standard says.
>
> False. You go too far.
So when you modified gcc's trampoline handling it was 'false'?
> > Given our attack model, it's required. For details please see the
> > docs at http://pageexec.virtualave.net/docs/ .
>
> Given that you are more than happy to break programs that generate
> native code inside their own images, False.
Who told you that i was happy with breaking programs? That's why PaX
features can be disabled both in the kernel configuration and on
individual binaries as well (or using ACLs under grsecurity). Last
but not least, what exactly is 'false' with the above? The statement
was about the PaX attack model and what is required to support it,
if you think the support is not required, prove it, preferably by
reasonable arguments, not sweeping comments.
> > The other approach is called SEGMEXEC and is based
> > on the segmentation logic. Its performance impact i don't know exactly
> > as i never tested it standalone,
>
> Never tested? So people are using the slow one?
Uhm, you didn't understand something. I never tested its *performance*
standalone. And i did tell you somewhere below that SEGMEXEC was the
default, did you miss it?
> W^X on i386 and all our other architectures has zero slowdown. On some
> architectures like sparc64 and powerpc, it actually sped the system up
> because we can avoid I cache flushes.
You're mixing up non-executable page semantics (what SEGMEXEC is about)
with restricting page protections, the two are different, even if the
latter requires the former.
> > There are bugs other than linear stack overflows which may still
> > allow a return-to-libc style exploit (and in your case, totally
> > circumvent W^X), what are you doing about them?
>
> Nothing yet. W^X is a piece of the puzzle. Just as your "killing exec"
> thing has nothing to do with this either.
It does, but if you didn't understand the PaX docs so far, it's
pointless to explain it again.
> > PaX doesn't require changes in (most of) userland to provide all
> > the protection features.
>
> And ours does, so that we do not suffer performance like PAX.
What performance do you 'suffer' under PaX (and which arch)?
> > No, PaX does not break mprotect(), it does what the standard allows.
>
> No, it breaks the standard and there are affected applications.
You keep talking about the standard and how it's getting broken by
PaX. Can you finally serve us with the details? As i showed you
already, restricting protection flag combinations is allowed, but
you have to tell userland about it, which is where OpenBSD itself
fails.
> > Besides, if an app does need the relaxed behaviour, it can be allowed
> > by simply setting an ELF header flag on the given binary.
>
> By modifying the binary. So much for it being a kernel-only change!
Wrong, the PaX security features require a kernel-only change (for now,
that is), when you do NOT want them is when you have to set a flag.
Beyond this, you don't need to touch any of your binaries if you're
using grsecurity whose ACL system allows to disable PaX features on
a per subject basis.
> > TLB handling is not slow in PaX per se,
>
> False. Execute bit emulation in PAX is slow.
Tell us please how you can do it significantly faster (remember,
here we're talking about the paging logic, not segmentation).
> > PaX is already part of several distros, mostly because they use
> > grsecurity. One can get it on Mandrake, Debian, Trusted Debian,
> > Gentoo, etc.
>
> And it is NOT ON BY DEFAULT! Can you not READ WHAT I SAID? I said
Did i say it was? Also, it's on by default in Trusted Debian.
> Can't you read? Do you have some built-in desire to purposefully
> misread what people say, just so that you can win your little
> arguments? Does it make you feel like a big man?
Weird, i thought i'd clearly avoided the word 'RedHat' when referring
to distros that use PaX.
> No, it is a bit unfair for people to say that what we've done in
> OpenBSD should give credit to PAX. Considering we'd never heard of
> PAX before we did W^X,
http://marc.theaimsgroup.com/?l=openbsd-tech&m=97416533704634&w=2
By the way, i saw in your CSW03 presentation that you're planning
mmap and main executable randomization. It's got nothing to do with
http://pageexec.virtualave.net/et_dyn.zip and PaX's ASLR, right?
> and considering that our goal was to NOT BREAK anything -- a goal
> you have NOT MET.
You mean a goal i haven't set? FYI, it was something like 'maximum
possible compatibility without sacrificing the protection features'.
There are people who value security over the ability to run Java.
> > You realize that you control everything
> > (kernel+userland) in OpenBSD which is not true in our case.
>
> Of course we do. And that allows us to NOT BREAK semantics.
You already start from a position where you break POSIX.
page...@freemail.hu
> provide. If my memory is correct, POSIX explicitely differs here, and
> states that:
What does it say about mprotect() and protection flag combination
support?
Dries Schellekens
> > So stop crying for credit. There is no credit to give to you;
> > we came up with it independently.
>
> I wasn't asking for credit nor do i question independent discovery
> (i did it myself a few times). I've been actually working on some
> docs on the history of these ideas (well, as far as i could track
> it in on-line discussions), so i'd appreciate if you guys could send
> me some of your logs/timeline/etc, to properly credit your work as well.
On deadly.org I've been discussing with the PaX team. They seem to have
trouble with the fact that in a previous mail Theo said "Considering we'd
never heard of PaX before we did W^X." They find it really suspicous that
art@ implemented stack-gap randomization (mentioned it the CanSecWest
presentation) in Augustus 2001 (after HAL2001, where they claim OpenBSD
developers were made aware of the existance of their project), just after
they implemented this feature in late July 2001.
http://64.90.164.50/commentShow.php3?sid=20030417082752&pid=290
Some features on the list of future work, mainly other randomization
features (Randomized mmap, Randomized mapping for shared objects, Try to
find a way to map the main program randomly), look similar of some of the
PaX features.
They seems to be eager in receiving getting credit for these features:
"Maybe i didn't express myself clear enough: i'm interested in full public
archives, not what an individual is willing to share, that is, it's not
only for myself but for all. It's a pity the OpenBSD community goes so
easily by this closed development process - i don't. If art or anyone else
has anything to say on history, they'd better make it available to
everyone. Besides, i made my request already clear on the misc@ list."
http://64.90.164.50/commentShow.php3?sid=20030417082752&pid=608
Can someone (Theo or art) comment on this?
Cheers,
Dries
--
Dries Schellekens
email: gwyl...@ulyssis.org