On 21/12/14 04:51 AM, Lukas Jirkovsky wrote:
Hello Daniel, thank you for the detailed explanation.
The address of dynamic libraries, the stack and the heap (both sbrk and the mmap base) is already randomized today so the backtrace is already going to include randomized addresses for anything defined in a library.
Sure, but knowing at least the source line where it crashed in the executable may help a lot even if the rest of the backtrace is useless.
It's possible to figure out the base address by using gdb on the core dump and looking at `i aux`. The AT_PHDR value can be rounded down to the page size and that's the base address. There might be an easier way to get it... From a non-PIE executable, where 0x400000 is the default base addr: 3 AT_PHDR Program headers for program 0x400040 This is with PIE and randomization disabled (0x555555554000): 3 AT_PHDR Program headers for program 0x555555554040 Here is a randomized one (0x7f2887981000): 3 AT_PHDR Program headers for program 0x7f2887981040 It's possible to map these back to the code just as you can do without PIE. The debugger itself is fully aware of the base address, even with no debugging symbols: #4 0x00007f21baf0c040 in __libc_start_main () from /usr/lib/libc.so.6 (i.e. it translates addresses to symbols whenever it can)
An executable is compiled as PIE is compatible with full ASLR but it doesn't force users to use it. ASLR can be disabled by setting /proc/sys/kernel/randomize_va_space to 0. It's also possible to do it for a single process (far better idea)
Oh, I didn't know that it's so easy to disable it. I would still prefer to have it enabled only for the core system and the applications that are a common point of entry such as web browser or web server, but I can cope with that if I can handle that by myself when everything is compiled with ASLR.
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.