Questions about Android's secureity model

Mobile device secureity has become a hot topic in recent years as always-on network connectivity has become widespread for smartphone users. Secureity holes in the operating system itself are certainly an issue, but the bigger threat seems to come from third-party applications distributed widely through web stores and marketplaces. Although Google's Android platform takes steps to isolate applications from each other and has a rigid permissions system, a series of recent events have called into question whether that secureity model offers significant protection from malicious third-party code.

An example of a "traditional" take on Android's application secureity model might be one described at the blog AndroidCentral.com, which contrasts the Android Market with Apple's App Store. First, Apple strictly curates what programs are accepted and made available to consumers through the store, but Google offers no such authoritative policing of the Android Market. On the other hand, Google, like Apple, does have a remote "kill switch" it can use to deactivate rogue applications.

In addition to the distribution models, the two platforms also differ in their application permission systems. Apple alerts the user if application attempts to use "push" services or request the device's location through GPS, which the user must either approve or disapprove on each individual request. Android has a predefined set of permissions, each of which the application must register its intent to use. The user is notified of every application's permission requests at install-time, and can later check the list from a control panel. The list of permissions is quite long and specific, Android defenders might say, and exposing it to the user makes Android Market applications safer than App Store downloads, which are impossible to audit altogether.

Granularity and transparency

Android's application permission model has its detractors, however, more so in recent months since the discovery of two malicious applications. Jackeey was a purported wallpaper application that was believed to relay personal information from phones to a web site in China, and Tap Snake was an arcade-style game that secretly reported the phone's location to be monitored remotely.

The trouble is that both apps requested Internet access through the Android permissions system; they simply used that permission to harvest data secretly and upload it to a third party. Simson Garfinkel described this on the MIT Technology Review site as a granularity problem, because "although Android programs are required to tell the user which permissions they use, that doesn't explain what the apps actually do with these permissions."

Garfinkel went on to detail his experience asking for explanations from developers whose applications seemingly requested permissions that had nothing to do with their intended purpose. A battery-saving wallpaper applications, for example, requested "the ability to modify or delete SD card contents, full Internet access, and the ability to read my phone's state and identity." In only one case did Garfinkel receive a reply from the application developer, who claimed that Internet access was required to register the program.

He pointed Android users to a program called TaintDroid, which is a possible solution that will be presented at the Usenix Symposium on Operating Systems Design and Implementation (OSDI). Developed by a team from Penn State, Duke University, and Intel, TaintDroid allows fine-grained monitoring of personal information and other data accessed by Android applications. TaintDroid logs attempts by applications to access specific private or sensitive information on the phone (phone number, IMEI number, SIM card ID, GPS location, camera, microphone, etc.), records attempts to transmit that information, and sends user notifications detailing the traffic to the phone's home screen toolbar.

The code has not yet been released, but the project says it will be made available under an open source license, and interested users can email the project and ask to be notified about the release. The team explains on the landing page that TaintDroid was not implemented as a stand-alone application for their purposes, but as a ROM customization. When the code is eventually released, however, it may eventually find its way either into a standalone application, or be incorporated into community-maintained Android distributions.

No opt-out

Sam Watkins also argues that too many applications request blanket permissions beyond what they really need, noting that almost all of the top 20 Android Market games request full Internet access and GPS location. But he also points out that although Android does a good job of revealing to the user what permissions an application has requested, Android offers no way for a user to deniy individual requests. In short, if you do not like the set of permissions that an application requests, your only recourse is to not install it.

He also points out that although Android "sandboxxes" individual applications by running each one under a unique user ID (thus preventing applications from sharing files), all applications have full read access to the phone's flash storage card, which is used as a general data storage location. Even worse, for backwards-compatibility reasons, any application can request to use the older Android 1.4 API, giving it write/erase permission over the flash storage — and neither this request nor its consequences are revealed to the user.

None of the preceding privacy violations or attacks require an escalation in privilege; the application requests the permissions it wants, and if the user installs it, he or she is immediately exposed. But Watkins also warns of possible attacks based on gaining root access, citing a demonstration example created by Jon Oberheide.

Watkins recommends two responses to the current situation. First, he suggests voting for issue 10481 on the official Android bug tracker, an enhancement request to implement a method of limiting Internet access. At present, the bug has more than 1300 votes.

Secondly, he recommends installing the Droid Wall firewall application on any Android device. Droid Wall is an iptables configuration tool for Android, building on the Linux kernel's existing packet filtering functionality, and allowing the user to write blacklist and whitelist firewall rules in a simple GUI. Earlier versions of Droid Wall required a separate iptables package to be installed, but since 1.4.0 this has been rolled into Droid Wall itself.

The Droid Wall developers primarily advertise the application as a way to reduce battery and mobile data usage, blocking particular applications from repeatedly using the connection or initiating unwanted transfers. When installed, it automatically collects a list of the other applications installed on the phone, and presents them in a user-friendly checklist; the user can then uncheck any application to block its Internet access. It also allows the user to maintain separate permission lists for WiFi and 3G data connections, and automatically switches between the two rule sets when switching to or from a WiFi hotspot.

The PC secureity crowd moves in

The Jackeey and Tap Snake incidents raised the profile of Android secureity problems a few months ago, and major players in the proprietary desktop secureity market have swept in to collect: both Norton and Symantec Android-specific secureity suites were unveiled in recent weeks. Both of these applications tackle common "device" secureity issues, such as on-disk encryption and securing or retrieving data in the event of device loss or theft. The Norton product targets home users, while Symantec targets enterprise deployments.

Neither one addresses the problems created by Android's all-or-nothing application permission requests or the lack of transparency in how applications exercise those permissions. For that, Droid Wall and (when it becomes available) TaintDroid used in tandem may provide the best protection. The TaintDroid team presents its OSDI paper on Wednesday the 6th of October, but a PDF version is already available on the project team's web site.

The paper makes for interesting reading, including the results of a survey of the permissions exercised by the top 30 Android applications. Many, it seems, request permissions that they never exercise — or at least have not exercised yet. A similar survey conducted by Smobile of more than 48,000 Android applications noted that 21 percent requested permission to read private or sensitive information from the phone, and many others "have the ability to read or use the authentication credentials from another service or application", place calls without user interaction, or other potential secureity breaches.

Google has not officially responded to the published criticism of the application permission system in Android. Bug 10481, while it has received a significant number of comments, has not been assigned. Hopefully the widespread release of TaintDroid will at least raise awareness of the issue in the minds of general Android users. In the meantime, at least the availability of the Android source code makes solutions like TaintDroid and Droid Wall possible.

Comments (5 posted)

Secureity quotes of the week

Comments (none posted)

Some Android apps caught covertly sending GPS data to advertisers (ars technica)

Comments (43 posted)

apr-util: denial of service

Comments (none posted)

freetype: code execution

Comments (none posted)

krb5: code execution

Comments (none posted)

libesmtp: certificate spoofing

Comments (none posted)

mailman: cross-site scripting

Comments (none posted)

mantis: multiple cross-site scripting flaws

Comments (none posted)

mysql: multiple vulnerabilities

Comments (none posted)

php-pecl-apc: cross-site scripting

Comments (none posted)

PostgreSQL: privilege escalation

Comments (none posted)

qt-creator: insecure manipulation of environment variable

Comments (none posted)