Exec-Shield and SELinux
Exec-Shield and SELinux
Posted Apr 19, 2007 20:16 UTC (Thu) by PaXTeam (guest, #24616)In reply to: Exec-Shield and SELinux by arjan
Parent article: A security analysis of two years of RHEL 4
what security technologies does RHEL4 have that make exploitation impossible? neither of those mentioned in the subject provides such a guarantee.
Posted Apr 19, 2007 20:19 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (12 responses)
The first part takes the actual circumstances of the exploit into account (say, the maximum number of bytes the buffer gets overflown is 10 bytes) while the later is a generalization and not relevant to the topic at hand.
Posted Apr 19, 2007 20:36 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (4 responses)
Posted Apr 19, 2007 20:50 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (3 responses)
second, as another commenter said, the double-free check doesn't prevent exploitation, it just makes it depend on a particular memory layout/content which may be hard or even impossible to achieve in a given situation, but without a thorough examination in every single case, you can't make a blanket statement like that - or if you do, better provide analysis of a few such bugs.
third, code execution is independent of double free exploitation - one is a bug class, the other is an exploit technique (i.e., one of many). what a double free gives you is a sort of 'mirrored write 4/8 bytes anywhere in writable memory' primitive. whether the exploit writer exploits it for code execution or something more subtle depends on what is better (and possible) for his goals. for non-control flow hijacking attacks i suggest that you read http://www.usenix.org/events/sec05/tech/chen.html .
Posted Apr 19, 2007 20:59 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (2 responses)
Second, I said that the glibc checks make most double free attacks effectively impossible, because what happens in the double free (as opposed to the general heap chain corruption case) is that the free'd elenment no longer is part of the chain AT ALL anymore, so the chain checks will just catch this. (In the general heap chain corruption scenario you can argue you can plant those values, in the specific double free scenario you can't argue that)
third, in the context of this article it's about the highest class of bugs, which do imply code execution or information leak as effect.
Posted Apr 19, 2007 22:22 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (1 responses)
Posted Apr 20, 2007 1:16 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Maybe there weren't any? Given that all this stuff has been done by Red Hat, maybe all involved just had a private exchange and decided to do it. Or something like that...
Posted Apr 19, 2007 20:37 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (6 responses)
> Sadly there is very little comment on how many if those critical issues
that's a very strong statement, better back it up with facts.
Posted Apr 19, 2007 20:39 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (5 responses)
Posted Apr 19, 2007 20:57 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (4 responses)
Posted Apr 19, 2007 21:01 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (3 responses)
I think you're acting a bit too paranoid here...
Posted Apr 19, 2007 21:17 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (2 responses)
PS: no need for ad hominem.
Posted Apr 19, 2007 23:01 UTC (Thu)
by k8to (guest, #15413)
[Link]
Posted Apr 20, 2007 1:37 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
After re-reading all Arjan's comments, I think Arjan believes these two technologies _could_ provide protection against those critial issues, not necessarily that they _would_. No?
you're misquoting me.. I did not say "impossible" I said "effectively impossible". There is a huge gap between "not exploitable in practice" and "not exploitable as a class as a whole in theory".Exec-Shield and SELinux
maybe as example to illustrate: the double-free protection that got added to glibc as part of the Exec-Shield project makes *most* double free attacks effectively impossible, because while a remote person may be able to trigger a double free, the checks in glibc remove so much freedom that it's no longer exploitable for executing code.Exec-Shield and SELinux
first, the double-free protection was published by Stefan Esser (http://www.derkeiler.com/Mailing-Lists/securityfocus/bugt...) and used in at least Gentoo prior to its incorporation in glibc, it had nothing to do with Exec Shield.Exec-Shield and SELinux
yes double free checking as concept wasn't new. Getting a whole set of that into glibc was part of the Exec-Shield project. I find it curious that you claim it wasn't... I don't remember you being part of that project.Exec-Shield and SELinux
to me Exec-Shield is this: http://people.redhat.com/mingo/exec-shield/ . if you have other projects under this umbrella, i must have missed their public announcements and the related discussions. can you point to some URLs where these glibc hardening and other discussions took place (i don't mean the cvs commit logs, but the actual design/implementation stuff)?Exec-Shield and SELinux
> must have missed their public announcements and the related discussionsExec-Shield and SELinux
i wasn't quoting you actually, but apparently 'effectively' means different things for different people (much like the "effective protection" term in the DMCA :-). that said, you still didn't answer my question under your interpretation. your original comment would now be rephrased as:Exec-Shield and SELinux
> were actually.. well not exploitable in practice due the security technologies.
> Could well be the vast majority of them....
I can back my statement up with facts easily: there was no comment about how many become practically exploitable in the article. You appear to read a lot more in my comment than there is.Exec-Shield and SELinux
that was only one part of your statement. the other and much more important one is the last sentence where you allude to your belief (or knowledge? i'm still trying to find out) that the majority of these bugs were not exploitable in practice - that's the strong statement (belief?) that needs proof or backing up with facts or plausible analysis. Exec-Shield and SELinux
I did not make such a statement. I said that I'd like to see how many of these type there were. YOU draw the conclusion about that I then think there are many of these, and then claim that that needs careful analysis on MY part before I can say that. Guess what... I was asking effectively if such analysis had been done and if there were numbers.Exec-Shield and SELinux
sure you did: first you clarified that 'effectively impossible to exploit' meant 'not exploitable in practice' then you said that the majority of these bugs could be in that category. now you tell me why you would make a post with two of those technologies in the subject if you didn't believe they would provide this level of protection...Exec-Shield and SELinux
colorful language does not an ad-hominem make.Exec-Shield and SELinux
> now you tell me why you would make a post with two of those technologies in the subject if you didn't believe they would provide this level of protection...Exec-Shield and SELinux