Re: Exec-Shield vs. PaX
> "The test incorrectly assumes that thread stacks are executable" is not
> equivalent to "thread stacks are non-executable". And there's no conflict
> in what i say above.
ok, i was quoting too much and you interpreted the wrong part. the bit
i was referring to is this:
> I suspect we both agree that it's desirable to have thread stacks
> non-executable as well.
on one hand you acknowledge that it's better to have non-exec thread
stacks but on the other hand you argued that
> it's not a bugfix to break apps that rely on an executable stack - the
> stack _is_ executable.
^^^^^^^^^^^^^^^^^^^^^
as they say, you can't have it both ways.
> > also, the test does not only demonstrate that thread stacks are
> > executable or not, it demonstrates a fundemental design flaw in
> > Exec-Shield: whenever an executable region is created in the address
> > space, *everything* below that becomes executable as well. [...]
>
> thanks, the cat is finally out of the bag - you admit here that the
> incriminating paxtest code is there to demonstrate what you characterise
> as a flaw in exec-shield.
the cat has always been out of the bag, way back in my very first mail
in this thread (and it's now the second time i've quoted this bit):
> 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.
since you have such a problem with paxtest doing the explicit
mprotect() itself i decided to change it to a simple nested
function, it will achieve the same and hopefully satisfy you
as well.
> Note that none of your arguments tries to claim
> that any real application indeed does "mprotect(argv)", which is pretty
> telling by itself.
indeed. if you read my mails again (i'm getting tired of quoting
myself all over again), i told you explicitly what paxtest is for:
testing for regressions, situations when stuff fails. Exec-Shield
fails under the above mentioned situation. it also fails when gcc
nested functions are used, you'll see that in 0.9.6. i hope you
won't argue that no real application uses nested functions (and
before you object even to that, as you said yourself, nested functions
are just one way to trigger the heuristics in gcc, other code
constructs from real life would do the same as well).
> As i have explained it a hundred times, this behavior is a well-known
> property of exec-shield, and that we've done a quite good job of reducing
> this effect. In fact i've put it into my exec-shield announcement:
*none* of your public postings discusses the inherent problem with
memory regions becoming executable when something above them does.
the quote from your README talks about the ascii-armor region and
data being executable in there. it does not talk about how the main
application's data or the heap or even the entire stack can become
unexpectedly executable. on a related note, PT_GNU_STACK support
as implemented in Exec-Shield suffers from the same problem: you
make not only the stack executable but *everything* else below it,
i could not find a note from you talking about it.
> ( sorry, but i'm going to stop contributing to this thread. You are
> getting increasingly irrational and emotional, there's nothing more i
> could add to this thread. I do acknowledge that PaX is more secure, but i
> also say that exec-shield is a hell alot of a difference from a stock
> distro. You expressed your feelings that exec-shield is insecure in one
> area and apparently you conclude that it's thus useless. There's nothing i
> can do to change this irrational bad logic of yours. )
Ingo, if you read one of my previous posts, you will realize that
i did say that Exec-Shield was mostly good enough against current
exploit methods (which blindly expect their injected payload to be
executable). what it's not good enough for is protecting against
future attacks which will (because they can) adapt and circumvent
Exec-Shield in certain cases. this is not true for PaX and obviously
that decides what i'm going to use (and have been for all these
past 3 years). and finally on a personal note: you're quick to
call people by names, that's not professional especially when none
of the facts support your position.
-------------------------------------------------------------------
i was not cc'd on this, but i'd still like to reply here:
Henning Makholm said:
> Hm, what I've been able to glean from the discussions seems to imply
> that any software that's vulnerable to a remote access exploit
> *without* the kernel-level protection in question, would still at
> least be vulneable to a DoS attack, killing the server (or whatever)
> process instead of giving the attacker actual control. So we'd still
> want to provide security updates to the same extent as without.
you're absolutely correct, there is *no* substitute to using correct
software. intrusion prevention systems exist for the purpose to
provide some level of protection until such an update can be made
and installed. there are many reasons why it may not always happen
in a timely manner. for one, there are bugs which are simply not
known publicly (the 0-day exploit case), or there're services/servers
which cannot be taken down in certain hours of the day (and the risk
of a DoS is still more acceptable than the risk of getting compromised),
or the system admin is simply too busy to install the update as soon
as it's released (full automation of software updates carries its
risks as well as i'm sure many admins can tell).
Reply to: