[arch-dev-public] Proposal: enabling full ASLR on x86_64 via hardening-wrapper

[Daniel Micay]

> 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:

http://www.openwall.com/lists/oss-security/2014/12/24/1

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...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20141224/48b5ff21/attachment.bin>