On 29 Jan 2016 at 20:23, Alessandro Di Federico wrote: > On Fri, 29 Jan 2016 18:13:23 +0100 > "PaX Team" <pagee...@freemail.hu> wrote: > > > On 29 Jan 2016 at 16:44, Alessandro Di Federico wrote: > > > > > On Thu, 28 Jan 2016 02:49:46 +0100 > > > "PaX Team" <pagee...@freemail.hu> wrote: > > > > nobody has ever shown that there exists such a bug (or set of > > > > bugs) and in fact there's ample evidence that already executable > > > > code contains all the necessary gadgets an exploit would need. > > Could you please detail better this "ample evidence"? Being so vague > while requiring so much burden of proof on my side is a bit unfair :)
the fact that the real life ROP exploits i've seen out there all make use of gadgets exclusively from (intended) code and not some data that happened to be mapped executable. note that i'm not claiming to have seen all the exploits out there but even if some exploits happen to use gadgets from non-code pages, it doesn't prove the value of --rosegment until one also proves that it is impossible to write the same exploits with gadgets from code pages only. add to this academic work like [1] and i believe you'll find yourself up against a rather high hill if you still want to prove the benefit of --rosegment ;). [1] Q: Exploit Hardening Made Easy https://www.usenix.org/legacy/event/sec11/tech/full_papers/Schwartz.pdf https://www.usenix.org/legacy/event/sec11/tech/slides/schwartz.pdf > I understand, and partly like, your practical approach, but security is > not just preventing a certain bug to from being exploitable. my approach is as much practical as theoretical, it is all based on a very generic and strong threat model, a full categorization of exploit techniques and corresponding defense mechanisms. i evaluate other defense mechanisms based on the same threat model and/or just plain common sense like in this case. > Nowadays exploits, as you know, often use multiple vulnerabilities, > while in the past a single one was enough. This makes attacker's life > harder, that's why we ASLR: it doesn't prevent an exploit, it just makes > it harder to exploit (e.g. you need an additional vulnerability). actually ASLR does prevent exploitation with a bounded probability absent of information leaks. if you're thinking of weak imitations then sure, you can brute force your way, but that won't work under grsecurity (you realize this is the gentoo hardened list, right? ;). > That's also why we have RELRO. yes, RELRO serves a quantifiable and useful purpose, which i have yet to see about --rosegment. > A common principle when designing a secure system is trying to reduce > the attack surface as much as possible, to decrease the chances that > an attack is feasible. And that's exactly what the countermeasure I'm > suggesting aims to do. the number of overall gadgets is not an attack surface. the number of any particular kind of gadget is one in that if it's 0 then the particular kind of gadget is unavailable for an exploit (which may or may not prevent exploitation). you haven't shown that --rosegment can achieve it for any particular gadget class on any particular binary, let alone all binaries mapped into a particular process (good luck with glibc btw ;). > I don't like to cite my own work, but take for instance the "leakless" > attack [1,2]: finding the various gadgets required to perform the attack > is not a straightforward task. The lesser the executable code, the > harder it gets. yes i know your work and i think you chose the very wrong choir to preach it to :P. for one, your attack assumes a setup without PIEs and BIND_NOW/RELRO which is kinda the anti-thesis of hardened gentoo. second, your attack assumes the ability to hijack control flow for which we also know the solution (various forms of CFI, i guess i'll stop at not citing my own work on it to be fair ;). last but not least, you haven't proved the 'harder' part in any quantifiable way i can see. like i said at the beginning, just show me *one* bug which is exploitable when .rodata is executable and isn't exploitable when .rodata is non-executable. > > there's nothing wasted here, quite the opposite in fact, the linker > > was smart enough to pull 3 segments into one physical page which > > minimizes page cache waste on the kernel side and disk block usage on > > the filesystem side. > > You're partly right. The kernel should be smart enough to use a single > physical page for both the 0x400000 and 0x401000 pages, despite having > different permissions, but for sure the last PT_LOAD needs a distinct > page, only when a copy-on-write fault hits it, which i'm not sure happens for a simple thing like hello world (i could certainly write one that would not need to write there since it's basically a write/exit sequence).
