Re: Exec-Shield vs. PaX
[metanote: as you can see, we're entering the meta-discussion part
and i can very well understand that it's of little if any interest
to most you (that includes me btw), so i'll try not to post more
here except maybe to discuss technical issues]
> > 1. 'It seems that exec-shield does 99% of what PaX does'
>
> this is not the case and i'm not claiming it. If you feel attacked, please
> dont - i'll stipulate that PaX gives better security than exec-shield, ok?
in case you didn't realize it, it was not directed at you either.
> > - PaX implements perfect non-executable pages on amd64, i386,
> > ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has
> > some imitation of it only on i386 (it's not true per-page).
>
> non-executable pages on anything else but i386 is a triviality, as the
> hardware and the kernel supports it. There's virtually nothing that PaX or
> exec-shield has to add to enable them - they are there.
that's what you say because apparently you have never checked
it let alone tried. here's a few of these 'trivial' questions
for you to answer:
1. how do you do per page non-exec pages on ppc/ppc64? hint,
there's no NX bit in their PTE format. try to answer that
without looking at PaX first ;-)
2. how do you do per page non-exec pages on mips/mips64? hint,
there's no split TLB (let alone NX PTE bit) in the base
architecture definition.
3. how do you do per page non-exec pages on sparc64 under
linux 2.6? hint, you've reused the last free bit in the PTE.
and linux didn't support NX on sparc64 even before 2.6.
4. how do you do per page non-exec pages on sh[34]? hint, there's
at most a 'half' split TLB only and no NX PTE bit.
5. how do you do per page non-exec pages without a TLB/MMU
(you did claim 'trivial' support for anything but i386)?
next, what will you do with the archs where the .plt is in the
rwx ELF segment and hence under your scheme would force all of
.data/.bss to become executable as well?
> lets also point out that exec-shield offers relative randomization of DSOs
> to each other, while PaX only randomizes a single base of the DSOs, their
> relative addresses remain constant. This way the randomization bits of
> exec-shield add up for brute-force attacks. Lets add it that if a limited
> exploit can be turned into an information leak then relative randomization
> does not help - but it does help if the first exploit itself needs precise
> addresses from multiple DSOs.
all correct, except for the fact that the whole exercise of per-library
randomization is pointless. i say that based on my experience in analyzing
bugs and writing exploits for them - admittedly something i can't share
with you, so feel free to think otherwise. what i can offer however is
a simple observation: if an attacker needs code addresses from more than
one library, then he can get them even under Exec-Shield. this is because
he can just use the .plt entries of the library whose base address he
learned via info-leaking. also, the most likely information leaks that
contain library addresses are on the stack - and you can imagine that
the stack will likely contain such addresses from more than one region,
hence there's little if any advantage of separate randomization.
in any case, you're missing the point behind randomization. it's an
obscurity feature, however efficient it may turn out to be in certain
cases. i did it because it was extremely cheap (speaking of the PaX
implementation, not Exec-Shield) so i said 'why not'. randomization
serves NO purpose in the grand scheme, it does not provide guaranteed
protection against the PaX attack model (arbitrary read/write access
to the address space). you don't have an attack model so you can say
whatever you want about the details of your randomization, they will
of course be 'true' by definition.
> > second, paxtest had some bugs which Exec-Shield exposed and made
> > Exec-Shield appear better than it is. i've fixed them here and
> > expect to release 0.9.5 today or so. the results now look like:
>
> ( how fair that you give me a chance to run it ... not. )
from the email headers of your answer:
Date: Wed, 5 Nov 2003 00:58:30 +0100 (CET)
From: Ingo Molnar <mingo@elte.hu>
paxtest 0.9.5 was released hours (!) before that, what are you talking
about?
> > (1) introduce/execute arbitrary code
> > (2) execute existing code out of original program order
> > (3) execute existing code in original program order with arbitrary data
>
> no.
no what? are you telling me you know of an exploit technique against
a memory corruption bug that does not belong to any of the above
categories? because that's what my statement was about.
> No offense meant, but i say so because right now i dont see the way to
> have a generic and usable Linux system with all the restrictions you are
> talking about. If you complete your project and everything works and it's
> still the same live, flexible and kicking Linux system that we all know
> and love then i was clearly wrong.
http://gentoo.oregonstate.edu/experimental/x86/stages/
(i apologize for the inadvertant advocacy here, it's just to show a
point, i don't want to start a distro war)
the above is the beginning of such work with full PIE and propolice
support. or if you're into server-land, check out Adamantix [1] (it
was released before Exec-Shield).
> Right now it seems to be heading more
> in the direction of a prison - but this is just my judgement. In any case,
> i did not want to add any of that to exec-shield. I'll leave the prison
> guard work to selinux.
you're mixing up intrusion prevention (PaX) with access control. see
more below for the 'prison' argument.
> you do realise that most of those 'exploit techniques' overlap with some
> programming concepts, and you think that those concepts are flawed by
> design and should be eliminated - i dont agree with this characterisation.
putting words into my mouth or can you actually quote me on that?
what i'm saying is that there are programming techniques (runtime
code generation in this case) that should be handled more carefully
than they have been. what PaX does by default FOR NOW is the result
of me being cautious (and i have not heard of a single PaX user yet
who did not appreciate it) and not having the resources to fix up
userland all by myself. this also brings me back to your 'prison'
argument and a bigger issue you seem to be not talking about:
you said a lot about what you don't agree with in PaX, what
exactly prevented you from changing it *yourself*? what prevents
*you* from disabling MPROTECT by default for example?
speaking further about the 'prison' thing, you said this earlier
in another thread:
> if you could get rid of the 1.5 GB VM limitation of PaX and if you could
> change it to use PT_GNU_STACK to set the process stack's protection bits
> then i think there's no need for exec-shield - PaX will provide better
> protection at no cost and no tradeoffs.
have you changed your mind since then?
> > - apps that by their nature want to generate code runtime (e.g.,
> > java). they're broken for good which many people noticed by now.
> > that's good, that was my purpose because i wanted to draw
> > attention to the fact that runtime code generation is an
> > important privilege that should be carefully managed (as it
> > happens to be also one of the exploit techniques). [...]
>
> i think here we are in a fundamental disagreement. To take it to the
> extreme, being able to 'generate code' [ie. allow an application to write
> code, etc.] is one of the fundamental properties of any Linux user
> account, and hopefully remains so in the future.
the ability to create/execute one's own binaries is a privilege
too, that's what ACL and Trusted Path Execution systems allow you
to control (before you talk about 'fundamental properties' please
ask some administrators of user accounts in a corporate or
government/military environment). in any case, this is no longer
about PaX but how a secure system is to be created - there are
as many approaches as many people tried, PaX is only one (piece)
of them.
> If you take that 'privilege' away you'll take away what drives
> Linux forward - a constantly growing pool of programmers.
i have the impression that you believe i'm trying to promote PaX
to enter the 'main' kernels in its current from. to be clear about
it: i am *not*. if someone wanted to do it, i'd have several
suggestions before that should happen. such as deciding what is
acceptable to be default, how it should be controlled (configure
or runtime, etc), how and to what extent buggy userland should
be fixed, etc. all these concerns are irrelevant in the current
discussion because we're talking about technical merits (or
their lack of) of different approaches, not how they should be
deployed in the 'real world' - that's a whole another problem
and requires more parties to participate.
> I dont want good security to rely on the
> system's insistence to remove the ability to generate code from as many
> codepaths as possible.
again, nothing is removed, it's just taken under control (as i said
above, don't mistake current PaX defaults with how it should be done
when the other building blocks are done).
> There's got to be another way to secure those damn
> apps ... the price you are willing to pay is i believe way too high.
good luck in your trying to fix the problem (speaking of the PaX attack
model again here), you'd be the first one to do it without the measures
that PaX takes.
> > about PaX breaking specs: i urge Ingo and others saying this to
> > point me to the precise location in SUSv3 or POSIX 1003.1-2001
> > that PaX conflicts with. [...]
>
> many areas of PaX conflict with one of the most basic rule of Linux:
>
> http://lwn.net/Articles/32980/
i hope you realize that Linus's declaration is not on the same level
as internationally accepted standards, don't mix them up. as for not
breaking userland: sure, that's what i'd like to have as well, but
i have only so many hours in a day to work on that. also, you did
break userland yourself as well, otherwise how would you explain the
patches RedHat made to the XFree86 server? see, there're just cases
when userland is plain wrong and must be fixed. on another note, how
did you get java to work under Exec-Shield while maintaining all those
non-executable regions (see more on this below)?
> > about SEGMEXEC and the 1.5GB limit: yes, it's true, yes, it could
> > be changed (if one can live with a more limited range for executable
> > mappings), [...]
>
> i'm not sure it's acceptable to put _any_ restriction on the layout of the
> user VM.
no problem, PaX as it is makes no restrictions on the layout, we'll just
be stuck with the 1.5 GB task size on i386 (or the usual 3 GB if you can
take the performance hit of PAGEEXEC on i386).
> The rule exec-shield follows is this: whenever the kernel gets a
> chance to chose it will group mappings smartly, but it will follow
> requests for executability no matter what. So while this doesnt _force_
> good protection, for most apps it provides a pretty acceptable layout.
>
> i guess this is a hard-to-solve philosophy difference again.
indeed, especially since your philosophy seems to be 'do something
while breaking absolutely no apps' where 'something' is yet to be
explained and whatever it is, you still broke apps with it (such
as XFree86).
> a fair number of users got real happy when we extended the x86 user VM
> from 3GB to 4GB. Going from 3 GB to 1.5 GB is really not an option i'm
> afraid. It's also not an option to say that "your app is secure only as
> long as it fits into 1.5 GB". It also not an option to say "this box is
> pretty secure, except for your huge database server".
that's your personal opinion. others (e.g., PaX users) have the
exact opposite as their personal opinions, so be it ;-). since
you've talked so much about what does not fit into 1.5 GB, could
you please provide us with a list of applications that are used by
the majority of users and fail when run in a 1.5 GB address space?
> obsoleted by ia64/amd64 systems anyway. But i'd hate to lose users to
> Windows just because distros only support 1.5GB of VM.
Windows has a 2 GB userland, seems to be closer to 1.5 than 3. other
than that, Microsoft is moving into the PaX direction [2] (i'm referring
to runtime code generation and memory protection in particular).
> i really dont think we can realistically isolate the code generation
> capability and still have a nice and flexible system.
it's not about 'isolation' (did you mean 'removal'?) but control.
control by the distro maker, system administrator or the end user.
what is subject to discussion how it should best be done. you say
it should not be done at all, that's your opinion and is in
complete disagreement with experts in the information security field.
> I dont see anything wrong in apps executing scripts. Or apps writing
> scripts and executing them. Or apps doing JIT stuff, or just doing
> some quick runtime fixup.
there's nothing wrong with it as long as you write bugfree code or
don't want guaranteed security from certain exploit methods. there
are people who want the latter because they have much at stake and
know that the former is not true.
> It's quite widely done and it would not be Linux anymore if we try to
> exterminate or second-class such techniques. And it's even more common in
> the Windows world, and i really hope those Windows apps continue to come
> over to Linuxland.
i know i'm repeating myself, but i'll say it again: there's no problem
with runtime code generation as long as it's under control. let's do it,
but be aware of it when it's done because it's a dangerous privilege
when abused. come up with a system that allows one to easily define and
maintain defaults and policies, and i'll be the happiest person.
> static predictable addresses. I dont think this should be tagged via the
> binary itself - that is too inflexible. There's already one 'VM size bit'
> in the personality mask in the upstream 2.6 kernel: the 3GB flag for
> amd64.
personalities are something i was thinking of before, but i had a
problem which i forget now, i'll take another look at it later.
> no, this is not how PT_GNU_STACK works. PT_GNU_STACK not only detects
> trampolines, but all those techniques that _might_ point in the direction
> of process-stack executability. Such as the use of inline assembly. So the
> toolchain pessimistically turns on executability and guarantees that _if_
> the object is marked non-executable, that it certainly needs no executable
> stack.
i was referring to this patch [3] which deals with trampolines only,
thanks for clarifying it.
> even the above conservative scheme gave a very high coverage rates, with
> just a couple of (well below 10% of all) important apps/libs falling out
> of the nonexecutability umbrella.
what about code not compiled by gcc? are all those users running with
an unsafe default (executable stack) or have broken binaries?
> To solve these cases, application writers/packagers can further improve
> the accuracy of this scheme by declaring said pieces of code as permitting
> non-executable, but it's the right place and the best way to document it:
> in the source. It cannot get lost, it will be updated when the code is
> changed, etc. Tags tend to get lost, or tend to get incorrect over time.
doing it in the source code is what i suggested as well, read the
proposal in mprotect.txt.
[now in order to save some round-trip time, i'll answer your second
mail here as well]
> i downloaded the new 0.9.5 paxtest package and amongst other changes it
> has the following oneliner change:
>
> --- paxtest-0.9.4/body.c
> +++ paxtest-0.9.5/body.c
> @@ -29,6 +29,7 @@
> fflush( stdout );
>
> if( fork() == 0 ) {
> + do_mprotect((unsigned long)argv & ~4095U, 4096,
> +PROT_READ|PROT_WRITE|PROT_EXEC);
> doit();
> } else {
> wait( &status );
>
> this intentionally calls mprotect(PROT_EXEC) for the highest possible
> address one can think of. This call has no useful purpose at all. In other
> words, this is a specific, underhand cheat to trigger 'Vulnerable'
> messages for all items when running paxtest on exec-shield kernels. Bravo!
> frankly, i've never experienced anything like this in my many years in the
> Linux world. You so far gave the impression of a reasonable and balanced
> person but this is as low as it gets. Shame on you.
several things come to my mind.
1. it's called paxtest for a reason. it's a regression test suite that
demonstrates basic exploit techniques and how PaX foils them (or not,
as the case may be). in case you don't understand 'regression', it's
not about what works, but what does not, therefore it is entirely
appropriate for PaX to show its strengths even under circumstances
where Exec-Shield fails. as i explain below, chosing between mprotect()
and threads came down to the usual question: what takes less time yet
demonstrates the effect (one line vs. a hundred or so in my case).
beyond all this, feel free to write your own suite.
2. did you miss this in my first post:
> Executable anonymous mapping : Vulnerable
> Executable bss : Vulnerable
> Executable data : Vulnerable
> Executable heap : Vulnerable
> Executable stack : Vulnerable
> the above changes are the result of Ingo's approach to create
> non-executable memory on i386, they're not per page as a simple
> mprotect on the top of the stack shows. before i get accused of
> specifically rigging the tests, i'll tell you that running
> multithreaded apps would have almost the same effect (only the
> main stack would stay non-exec under Exec-Shield). needless to
> say, PaX passes all the above as before.
do you understand what i'm saying there? did you also check the
changelog which says this:
* Non-executable page tests expose incomplete implementations
do you disagree that paxtest exposes a weakness in Exec-Shield
or not? do you disagree that the exposed weakness can very well
occur in real life or not?
let me get back to the topic of java as i promised above. java
is a nice animal as it shows several issues with Exec-Shield.
first of all, it's multithreaded. glibc creates executable
thread stacks by default. unfortunately for Exec-Shield, when
such stacks are created, everything below them becomes
executable as well, even if it was not requested by the
application. you call that a feature i assume, i call it a bug
(if i mmap() something without PROT_EXEC i don't want the OS
to change it to executable behind my back - *that* is really
not compliant with standards).
second, java has a small piece of executable code in its
.data segment - that should break it quite early during
startup. how come you never run into it if, as you claim,
.data is non-executable?
3. you and others have (ab)used paxtest long enough to justify
the approach taken by Exec-Shield while 'forgetting' to point
out the weaknesses/limitations (e.g., show me a single post
of yours where you discuss the problem with multithreaded
apps, or the more generic issue of unexpected and standard
breaking memory protection changes). forgive me if i'm not
willing to assist to this any longer, but *that* would make
me feel really ashamed.
[1] http://adamantix.org
[2] http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnwxp/html/securityinxpsp2.asp
[3] http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00302.html
Reply to: