ASLR in Android Ice Cream Sandwich 4.0

Via Duo Security Blog -

For the uninitiated, ASLR randomizes where various areas of memory (eg. stack, heap, libs, etc) are mapped in the address space of a process. Combined with complementary mitigation techniques such as non-executable memory protection (NX, XN, DEP, W^X, whatever you want to call it), ASLR makes the exploitation of traditional memory corruption vulnerabilities probabilistically difficult.

However, ASLR is commonly an all-or-nothing proposition. If ASLR is not applied to all areas of memory in a process, its effectiveness is often nullified. A single executable mapping that is mapped in a static location in the address space is often sufficient to construct a ROP payload. For example, this was the indeed case with the OS X prior to 10.7, where the dynamic linker was not randomized, providing a sufficient gadget source for a ROP payload.

So, let’s take a look at this new-fangled ICS 4.0 platform and see if ASLR was properly and fully implemented.

[...]

Unfortunately, the ASLR support in Android 4.0 did not live up to expectations and is largely ineffective for mitigating real-world attacks, due to the lack of randomization of the executable and linker memory regions. It also would be beneficial to randomize the heap/brk by setting kernel.randomize_va_space=2.

In addition to ASLR, Android could certainly stand to beef up some of it’s other exploit mitigation mechanisms. Non-executable memory support was recently added and GCC’s stack protector is now enabled in the default NDK CFLAGS, but other mitigations are still lacking. RELRO is missing allowing GOT overwrites as demonstrated in Stealth’s GingerBreak exploit.

I’d also love to see code signing support similar to iOS, which prevents the introduction of new executable code in an address space. In addition, code signing would hamper the ability to pull down additional malicious code at runtime, a technique I demonstrated two years ago at SummerCon that the RootSmart malware authors have recently adopted.

Let’s just hope that we don’t have to wait for another major version release of the Android platform to get the same exploit mitigations that have been available on desktop and server platforms for years.

As Dug eloquently summarizes below: “TL;DR: ICS ASLR = FUBAR”

UPDATE: Nick Kralevich from the Android Security Team provided the following updates in the comments below:

• kernel.randomize_va_space is set to 2 in ICS 4.0.3, randomizing the heap/brk mapping.
• Support for randomizing the linker mapping will be available in a future Android release.
• Support for randomizing executable mappings (PIE) will be available in a future Android release.

Sounds promising! We’ll be sure to check back in when those updates are live!