Mobile Device Security is a Bit Different
Let’s step back for a bit and examine the way that the security of mobile operating systems has been implemented. Both Android and iOS have UNIX-like cores and depend heavily on the kernel to enforce their app permission systems. Both operating systems limit the ability of both the user and applications to execute processes with administrative privileges. Android in particular has a very well executed “sandboxing” system that runs each app as a separate user and protects each app from directly accessing the data of another.
Currently, both the Android and iOS security models depend on the user not having full access to a device they have in their hands. At the same time, both OSs have a plethora of utilities and methods for interacting with the system that are, and must be, available to end users as well as apps. It is this incredibly complex ecosystem that both enables the richness we demand from mobile apps and greatly increases the chance that unintended bugs are present, such as privilege escalation vulnerabilities which allow an application to gain “root” privileges even on devices that were not previously “rooted.”
The solution to this in desktop and web applications is to use very strong perimeter security by incorporating strong passwords or other well vetted security systems.
The difference on mobile devices is that inputting strong passwords is slow and frustrating. Alternative less secure mechanisms, such as 4 digit PINs, are increasingly relied upon to provide the same level of security as a strong password on a desktop computer. Because the level of security required to access these application is so much lower, it is not realistic to rely on these same mechanisms to protect extremely sensitive information.
“Whether ‘rooting’ by itself is a problem or not is debatable, however, the fact that much of the security of these devices currently depend on restricting users from the full power of the device is a significant weakness of the model.”
What is “Rooting?”
Rooting mobile devices is analogous to having administrative access to your desktop computer. Rooting is sometimes achieved through semi-official means, such as those provided by Google for their Nexus phones, and other times through software vulnerabilities that inadvertently allow “privilege escalation” (like the way that iOS must be “jailbroken”). The Digital Millennium Copyright Act (DMCA), as a case in point, had to have a special exemption added to it to allow rooting under “fair use.” While not illegal, the act of “rooting” is viewed by device manufacturers and carriers as taboo and they generally refuse to support or service “rooted” devices. Whether “rooting” by itself is a problem or not is debatable, however, the fact that much of the security of these devices currently depend on restricting users from the full power of the device is a significant weakness of the model.
Why Do Users “Root?”
With a “rooted” device, users can remove “bloatware,” install customized versions of the operating system, often referred to as “ROMs” (to improve performance and/or add new features) and even block advertisements. In the case of iOS, it enables users to install apps that are not approved by Apple (this is a native feature of Android).
Traditionally, the process of rooting a device begins with a user first unlocking the bootloader. Most, if not all, new phones and tablets today, even the Nexus line from Google, are shipped with a locked bootloader. This means that the device verifies the integrity and authenticity of the software loaded on the device, that it has come from the manufacturer, and that it has not been tampered with. When a device’s bootloader is locked, it cannot be permanently rooted and no custom firmware, or ROM, can be installed on the device.
Some devices, like the phones in Google’s Nexus line, have semi-official methods for unlocking the bootloader. By design, this process triggers a factory reset of the software on the device. The benefit of this is that any sensitive information available on the device before unlocking the bootloader will not be present after unlocking the bootloader.
Depending on the OS to reset the software upon unlocking the bootloader is in some ways effective, but still insufficient as a security model for the following reasons. First, users who choose to root their devices will likely just re-add the data that was there previously by restoring backups. Second, not all devices, especially older ones, have locked bootloaders and are not subject to this restriction. Third, privilege escalation vulnerabilities completely bypass this restriction and are ripe for exploit by malicious apps.
“The fact that these vulnerabilities exist and that neither Android nor iOS are immune should bring to the forefront a discussion on the merits of depending on the operating system security itself for storing extremely sensitive material.”
Less Sexy, But No Less Significant
Privilege escalation vulnerabilities, where an unintended consequence of seemingly unrelated actions causes the privilege of the “current user” to be elevated to “root,” aren’t the sort of thing that make front page news, at least not on their own. It isn’t until someone finds a way to jailbreak their new iPhone that these issues start to make headlines.
The fact that these vulnerabilities exist and that neither Android nor iOS are immune should bring to the forefront a discussion on the merits of depending on the operating system security itself for storing extremely sensitive material. There are more secure approaches to storing this material, such as storing this data in an encrypted container with a strong password, by keeping some parts securely “in the cloud” or protected by an NFC secure element. Though with this security comes greatly increased development complexity and possible new hardware requirements.
“We were able to test this code and achieve root permissions on our Galaxy Nexus running the latest stock software without losing any preexisting data on the device.”
Yes, Android 4, Ice Cream Sandwich, Has Privilege Escalation Vulnerabilities
The latest Android OS available for the Galaxy Nexus phone is, at press time, 4.0.2 (ICL53F). The Linux kernel running in this version of the software is 3.0.8-gaaa2611. This kernel is vulnerable to CVE-2012-0056, the details of which can be found here: Vulnerability Note VU#470151 and Vulnerability Summary for CVE-2012-0056. The Linux source code has already been patched, beginning with version 3.0.18, to address this issue and the fix will most certainly be including in upcoming versions of Android.
This vulnerability allows any locally authenticated user to achieve root privileges by manipulating files in /proc/ /mem.
There is proof of concept code, not developed by zvelo, for Android available here: https://github.com/saurik/mempodroid.
We were able to test this code and achieve root permissions on our Galaxy Nexus running the latest stock ICL53F without losing any preexisting data on the device. This would enable a malicious app to access the Google Wallet PIN, and any other data on a vulnerable device without it being pre-rooted.
There are almost certainly other privilege escalation vulnerabilities within Android and iOS and it is likely just a matter of time before they are discovered and become publicly known. It would be better to take a more defensive approach to securing mobile devices that assumes that such vulnerabilities will continue to be found and exploited.
Remember too, that privilege escalation vulnerabilities can be exploited without physical access to the device. Malicious apps could gain root privileges, read any data on the device and send it back to a server on the web – and it can do all this silently. All a user would have to do is install a malicious app then all bets are off.
What’s Next?
The field of mobile device security forensics is still in its infancy. However, what appears clear is that these devices are no less vulnerable than their desktop and web-based counterparts. To the contrary, it seems that some of the secure coding practices, shouted from the rooftops and largely adopted by developers over the last few years, have not been treated as requirements in mobile apps.
However, due to the sheer quantity of sensitive information contained on these devices, they are already bigger targets than their desktop and web based counterparts. As I reported from the Black Hat Security Conference in Las Vegas in 2011, mobile exploits are already commanding a 30% premium on the black market over desktop ones.
We are just scratching the surface of this rapidly evolving field. A great deal of thought has been put into the security of these devices by some of the brightest minds in the field. To dismiss mobile operating systems as inherently insecure would be a great disservice to the developers as well as end users.
That said, it is unlikely that either power users’ desires to root their devices or software vulnerabilities that grant privilege escalation are going away. Given that, we believe continuing dependence upon kernel based privilege isolation, for mobile app security of extremely sensitive data like that contained in Google Wallet, to be insufficient. Further, we would implore the development community to use other means to store this information and to refuse to store it in accessible places of the device – rooted or not.
