Android 4.1 Jelly Bean Includes Full ASLR Implementation

Apple’s iOS and Google’s Android have been on opposite ends of the security continuum for the last few years, with iOS remaining resistant to malware and Android becoming a frequent target for attackers and malware authors. Google has been taking steps to change that in recent releases, and the latest version of its mobile operating system, Android 4.1 Jelly Bean, includes several new exploit mitigations and a more extensive implementation of ASLR to help defeat many kinds of exploits.

Android JellybeanApple’s iOS and Google’s Android have been on opposite ends of the security continuum for the last few years, with iOS remaining resistant to malware and Android becoming a frequent target for attackers and malware authors. Google has been taking steps to change that in recent releases, and the latest version of its mobile operating system, Android 4.1 Jelly Bean, includes several new exploit mitigations and a more extensive implementation of ASLR to help defeat many kinds of exploits.

Google first included ASLR (address space layout randomization) support in Android 4.0, known as Ice Cream Sandwich in Google’s dessert-centric nomenclature, but that implementation was only a partial solution. The ASLR support in Android 4.0 only randomized certain key locations in memory and did not prevent some common return-oriented programming attacks. Several other key parts of the Android operating system memory space were not randomized.

That’s changed with version 4.1. One change made in the new version is the addition of position-independent executables 

“As we mentioned in our previous post on Android ASLR, the executable mapping in the process address space was not randomized in Ice Cream Sandwich, making ROP-style attacks possible using the whole executable as a source of gadgets. In Jelly Bean, most binaries are now compiled/linked with the PIE flag, which means they will be properly randomized when executed,” Jon Oberheide of Duo Security wrote in an analysis of Jelly Bean’s exploit mitigations.

Google also randomized the heap in Android 4.1, as well as the linkers. 

“The custom Android linker was the last piece of the ASLR puzzle that was not randomized in Ice Cream Sandwich. In Jelly Bean, the linker is now randomized in the process address space. This means that the deficiencies in ICS pointed out in our previous blog post have all been addressed in Jelly Bean, giving it full stack, heap/brk, lib/mmap, linker, and executable ASLR,” Oberheide said.

The addition of full ASLR is a step in the right direction for Android, but there is still work to be done.

“While Android is still playing a bit of catch-up, other mobile platforms are moving ahead with more innovation exploit mitigation techniques, such as the in-kernel ASLR present in Apple’s iOS 6. One could claim that iOS is being proactive with such techniques, but in reality, they’re simply being reactive to the type of exploits that typically target the iOS platform. However, Apple does deserve credit for raising the barrier up to the point of kernel exploitation by employing effective userspace mitigations such NX, ASLR, and mandatory code signing. Thankfully, Android is getting there, and Jelly Bean is a major step towards that goal,” Oberheide said.

“Now that ASLR is implemented ‘fully’, it will certainly drive more interest towards the inherent weaknesses of 32-bit ASLR and other more platform/architecture-specific ASLR bypasses. Expect to see analysis showing just how weak ‘full ASLR’ is entropy-wise when dealing with the constraints of a 32-bit address space. When you start digging into the implementation-specific details of exploit mitigations, hilarity often results (case in point: the 1 bit of entropy in Windows stack cookies),” he said.

Suggested articles