Jelly Bean Implements Higher Level of Security
Posted July 19, 2012 at 09:00 am by jerdog
A lot of hullabaloo has been made about the security of today’s mobile OS’s, and for good reason. BlackBerry for the longest time was considered to be the most secure, and was the smartphone of choice for the U.S. Government. This has changed in the last year, with the NSA even releasing it’s own white paper on an Enterprise Mobility Architecture focusing on securing Android 2.2.
Any OS tends to suffer from a single point of failure—the user. Sure you can lock down your device with a password, but the responsibility to have a strong password lies at the feet of the user, not the OS.
Android 4.0 implemented a feature widely used in desktop computing as far back as Windows XP called Address Space Layout Randomization (ASLR), which effectively rearranges the positions of key data in memory address space. This feature dramatically reduces the ability of a hacker to predict target memory address areas and seek out exploits. Security researcher Jon Oberheide had this to say about the challenges of implementing ASLR:
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.
He then went on to comment on the implementation of ASLR in Android 4.0:
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.
- ProPolice to prevent stack buffer overruns (-fstack-protector)
- safe_iop to reduce integer overflows
- Extensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and to prevent chunk consolidation attacks. Chunk consolidation attacks are a common way to exploit heap corruption.
- OpenBSD calloc to prevent integer overflows during memory allocation
- Format string vulnerability protections (-Wformat-security -Werror=format-security)
- Hardware-based No eXecute (NX) to prevent code execution on the stack and heap
- Linux mmap_min_addr to mitigate null pointer dereference privilege escalation (further enhanced in Android 4.1)
- Address Space Layout Randomization (ASLR) to randomize key locations in memory
- PIE (Position Independent Executable) support
- Read-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)
- dmesg_restrict enabled (avoid leaking kernel addresses)
- kptr_restrict enabled (avoid leaking kernel addresses)
According to Oberheide, in his most recent analysis of the security of Android 4.1 and the above implementations Google has made:
While Android is still playing a bit of catch-up, other mobile platforms are moving ahead with more innovative 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.
It would seem that Google continues to move forward with their embrace of higher security for Android, but let us hope that their increased security does not come at the cost of reduced control and access for the development community, which in large part has contributed to the success of Android.
To read more about ASLR and mobile security check out Oberheide’s article.
Want something on the XDA Portal? Send us a tip!