When I switched from Blackberry to Android, my main concern (aside form losing BBM) was security. I heard rumors, which I took with a grain of salt. But with ASLR, Android 4.1 is said to be the most secure OS from Google to date. From what I gather, Google’s ASLR (Address Space Layout Randomization) works similar to an ever-changing IP, so to speak. It randomized the software’s memory layout in order to prevent those Trojan apps from grabbing onto your device. Pretty clever! Are we on a new path in terms of software? Maybe not. But it is a step in the right direction. Read more after the break.
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 Securitywrote in an analysis of Jelly Bean’s exploit mitigations.
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
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.