6

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.

4

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.

| improve this answer | |
  • NX is standard for a while now, as I understand, and return-to-libc (return to existing code, in general) is more common attack vector. As I see it, with this "offset" ASLR, finding out location of any piece of code gives out locations of all present executable code. Even with library load order randomization, finding it restricts search space for other functions to 2x amount of executable code, which also kills a lot of entropy. Am I wrong somewhere? Is finding some arbitrary function about as hard as finding specific one we need? – EvgEnZh Nov 23 '16 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.