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 :)
I understand, and partly like, your practical approach, but security is
not just preventing a certain bug to from being exploitable.
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). That's
also why we have RELRO.
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.
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.
Also, there are a couple of tools which require a set of gadgets to
automatically build ROP chains (so called "ROP compilers", e.g. [3]).
Reducing the amount of binaries on which they work increases the
security of your system. Same argument on more versatile tools such as
nROP [4], which don't require a fixed set of gadget but try to play with
what they have. In this case we might make their life harder, and make
them produce longer ROP chains, which is a critical factor in the
evaluation of the feasibility of an exploit. Try a run of
find -name "*.rb" -exec grep "'Space'" {} \;
in your metasploit directory to get an idea of the average space
available for exploits.
Also, quite often, developers try to isolate Internet-facing deamons in
small programs (take a look at DJB's qmail), making them even smaller by
reducing the amount executable code sounds like a good idea to me.
Not to talk about works trying to remove gadgets at compile-time *on
the actual code* [5], ignoring `.rodata` and the like. But Gentoo will
probably never use those, so it's less of an argument :)
> > and there are 0x410 wasted bytes of memory due to `--rosegment`
> > (the second `PT_LOAD` is mapped at 0x401410), in addition to the
> > 0x728 which are wasted due to the RW segment.
>
> 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, so its first 0x728 bytes are effectively wasted. But this is an
unrelated issue.
> you have yet to demonstrate that it's a countermeasure against
> anything ;).
First I have to convince myself that the countermeasure I'm suggesting
is fully effective! Which is not the case for how `--rosegment`
currently works. :)
--
Alessandro Di Federico
[1] https://clearmind.me/leakless.pdf
[2]
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/di-frederico
[3] https://github.com/pakt/ropc
[4] http://aurelien.wail.ly/nrop/
[5]
https://www.acsac.org/2010/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=121&type=2
