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

[Daniel Micay]

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.

-------------- 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/20141221/6e3fec6b/attachment.bin>