On 29 Jan 2016 at 20:23, Alessandro Di Federico wrote:
> On Fri, 29 Jan 2016 18:13:23 +0100
> "PaX Team" <pageexec@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" <pageexec@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).