ASLR in Linux does not randomize libraries separately

Question

I was trying out how ASLR works in Centos 7.2.1115 x86_64 specifically.

Here are my /proc/$pid/maps dumps from two runs of Firefox (on Pastebin): #1 #2

Basically, ASLR works. It randomizes .data and .text offsets.

However, it packs all libraries and executable in the same order and without gaps. (Well, mostly. There are couple variations, but they look purely accidental.)

So, as soon as single address gets compromised, this whole part of ASLR goes out of the window.

My question is, is it the common case as of now? What systems address this issue and how?

I mean, 64-bit address space is huge, you could just randomly throw each library at it and then check if it overlaps with anything, and successfully place it after a couple retries at most. Yet, the best already implemented solution I found by googling is library load order randomization on Android.

Answer 1

However, it packs all libraries and executable in the same order and without gaps. So, as soon as single address gets compromised, this whole part of ASLR goes out of the window.

Not quite. ASLR still works for reducing the chances of blind exploitation, helping to prevent an attacker from reliably jumping to an execution point. If you don't know a particular point to overwrite, then your next tactic is to NOP sled nearby memory anyway. Coupled with the starting address being randomized, you're just as likely to pick something off in never-land as useful code regardless of fragmentation.

I mean, 64-bit address space is huge, you could just randomly throw each library at it and then check if it overlaps with anything, and successfully place it after a couple retries at most.

True, but that incurs a performance issue. Every randomization entry is going to require an entry in the TLB, resulting in higher resource utilization and more wasted / unused memory due to block alignment.

My question is, is it the common case as of now? What systems address this issue and how?

For the reasons state above, it is indeed the common case. Understanding the limitations of the attack helps with understanding why using the more expensive "bits of memory everywhere" has limited benefit.

A bonus point: the most common exploitation is writing too much data to a data block, then executing it. The NX bit is also a substantial countermeasure.