> 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.
signature.asc
Description: OpenPGP digital signature
