Android's openness and public scrutiny will contribute to its security improvements.
Android’s openness gives its community and the market influence in the prioritization of Android’s improvement. Android product managers must have a challenging job, because so many other developers, users, contributors and ODMs have the ability to influence the direction of Android’s evolution. Openness also benefits Android through community-generated value.
In Android 4.1, there are under-the-hood improvements, identified by the community and built by the Android team. The quarter-over-quarter decline in Android malware reported by McAfee speaks to such improvement. The increased market share of Android 4.1 is the reason. Independent security analysts had reported that in older versions of Android system modules were loaded into fairly predictable base addresses so a clever hacker who found an exploit to deliver his malware code into Android could identify the location of the linker and cause the malware to execute. Android 4.1 prevents this with ASLR (address space layout randomization) that randomizes the base addresses of system modules, making them unpredictable so this type of malware stopped working.
Public release of the source subjects Android to analysis and reporting of vulnerabilities. Android manages to benefit from this dynamic, continually improving quality and increasing marketshare. Veracode, a security vulnerability assessment software and services provider, has been contributing to the identification of Android vulnerabilities.
A vulnerability recently presented by Veracode at the EuSecWest conference is the over-granting and less frequently under-granting of Android “permissions.” There are over 2,800 API classes in the current version of Android and 130 permissions. APIs are constructs that developers can use to invoke a system capability from within a program, such as sending a text message or reading the phone’s geolocation. Android, with its Linux heritage, has very fine-grained security, preventing the use of APIs without first granting permissions. Ideally, a mobile app should have exactly the right number of permissions, no more and no less, because this prevents misuse of private data or the potential execution of malware.
Ordinarily, finely grained security is advantageous; however there are two problems that lead to over- and under-granting of permissions. First, in order to account for software re-use, sometimes developers grant more permissions than they need because they want to prevent a potential execution exception occurring when the application functionality increases and exceeds the permissions granted.
The other problem occurs because of unclear or non-existent documentation that would explain what permissions are needed for a given API. This inevitably leads to over granting because the developer needs to exclude the API permissions from causing a bug. An example might be that the developer grants a Bluetooth API not only communications permissions but also administrative permissions to perform functions, such as pairing with other Bluetooth devices, when there is no reason to include administrative permissions. Andrew Reiter, a Veracode security researcher, explained “this ordinarily is not a problem with benign apps, but malware linking to this software could set up Bluetooth communication with a device such as a keyboard or headset and interact with the Android device.”
The solution is for developers to more accurately specify API permissions. In some cases, Zach Lanier, another security researcher at Veracode, suggests that “Android documentation is lagging the release of its functionality.” A map of all the APIs to the requisite permissions would give developers this capability. Implementation of the map might be via an Eclipse IDE plug-in.” In Lanier’s view, “Google’s Android group is the most motivated party to build such a map.” Veracode has also experimented with a software alternative that could initiate an API and return the permissions.
Each Android app installed delivers a manifest that declares the permissions needed by the app. In theory, Android could read the manifest and report to the user what permissions were granted to the app and offer the option to revoke them. Most users would be confused by the raw permissions. This was the case with BlackBerry and Windows Vista’s challenges to the user to approve or revoke granular permissions. Most often, when the user selected something other than the developer’s default permissions, the custom selection broke the application.
Lookout delivers a useful capability in its paid version. One function lets the Android user review the permissions granted to an app in plain English, such as “track location” or “access contacts.” Maybe not all users will understand nuanced permissions, but Lookout makes obvious conflicts such as a music app reading your contacts or messages clearly apparent.
Proprietary software projects do not share this advantage of large numbers of independent developers testing the software for bugs and vulnerabilities and reporting them or fixing them. In this case, Veracode has defined the permissions misuse issue and posed potential solutions. Lookout has seized the opportunity presented by over granting of permissions and added a compelling feature to its Android security suite.
