> "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).
