[arch-dev-public] Proposal: enabling full ASLR on x86_64 via hardening-wrapper
danielmicay at gmail.com
Wed Dec 24 20:13:41 UTC 2014
> The problem is that it's important for anything doing networking, any
> executable with setuid/setcap/setgid and anything run by users on
> untrusted input like image viewers, text editors and tools like file and
> strings. If `python` or `ruby` isn't PIE, then it's trivial to exploit
> heap buffer overflows in native libraries used by anything written in
> those languages, etc.
> There are cases where you can rule out untrusted input, but I think
> they're a rare exception. For example, there's no use in hardening the
> `ldd` binary - but `lddtree` doesn't trust the code so it'd be nice if
> the interpreter it runs as (Python) was hardened.
These recent imagemagick vulnerabilities are a nice example:
It's often exposed to attackers through web apps where they're used to
resize, compress and/or convert images provided by the users. PIE would
be a forbidable defense for a situation like this because the attacker is
not going to be able to use an info leak to obtain the base address. They
will be forced to brute force through the ASLR, which will take a really
long time, especially if the web app rate limits uploads. PaX has brute
force protection so it'd take decades or even centuries to exploit it.
It also ignores our CFLAGS, so it doesn't have SSP if it's not built with
hardening-wrapper or patched:
% checksec --file /usr/bin/convert
RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH /usr/bin/convert
However, SSP isn't going to help against issues like the heap overflows
that were found but it will mitigate some vulnerabilities.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the arch-dev-public