Android's permissions-based security system is an elegant idea. Informing us what phone capabilities -- permissions -- a third-party app wants before the software is installed, and the opportunity to stop the loading process if we don't like what permissions the new app is suggesting it needs.
What if the Android permission process is flawed? So much so, an untrusted application could send SMS messages, record conversations, or erase data from the smart phone -- all without user consent or knowledge.
William Francis -- fellow TechRepublic writer -- and I flirted with the idea in Android's permission system: Does it really work? William built a demonstration app for Android Market that could use a phone's GPS, even though the app did not have permission.
Recently, our suspicions were confirmed by Professor Xuxian Jiang -- a prolific Android bug hunter and my advisor for Bad apps: Avoid them. He and members of his North Carolina State research team, Michael Grace, Yajin Zhou, and Zhi Wang discussed the same problem in their paper, Systematic Detection of Capability Leaks in Stock Android Smartphones.
How permissions work
My understanding of Android permissions is a bit hazy -- not a good idea, since it's my article. So I asked William for help.Kassner: Can you explain how permissions work, so even I understand? Francis: To start, you need to understand how the inter-process communications model (IPC) works on Android. Here is an example.
Say I wrote an app to display PDF files on the phone. I don't want to make someone open my app every time they wish to view a PDF. So I expose a public intent that names the app. That way developers do not have to include code to open PDF files in their apps. They simply scan the phone for my app to make sure it's installed, call the correct intent, and finally send a request to open the PDF.
What if -- instead of an app for PDF files -- I write one that uses the phone's GPS. And, I expose the GPS capability via a public intent, in the same manner as my PDF app. The result would be the same; other apps can reach the GPS function.
This is how I exploited the GPS function in our article. The power widget had a public intent for controlling the GPS function. My app didn't have permission. So, I leveraged the exposed interface in the power widget and let it toggle the GPS on my app's behalf.
In that particular case, it was the worst possible scenario for the end user because the power widget came preinstalled on the phone's Read-Only Memory (ROM). This means Google or the device manufacturer agreed to let the power widget toggle the GPS, and because it was installed in ROM, the user didn't know the leak exists nor had the choice of removing it.
Remember how William's app stole permissions from a preinstalled application? At the time, I'm not sure either of us understood the significance of exploiting a preloaded app. But we do now.
Preinstalled apps as part of the "development inner circle" are trusted and given more rights. The screen shot below displays permissions automatically given to a preinstalled application:
If the preinstalled app with these permissions works as William described, a malicious third-party app could invoke any one of the above permissions. And there's a lot to choose from.
Those in the digital badlands understand the implication, hence, the research team's focus on preinstalled applications.
The research team named what we've been discussing. They call it a "capability leak". The researcher further divided capability leaks into:
- Explicit: Allows an app to access certain permissions by exploiting publicly-accessible interfaces or services without requesting the permissions itself.
- Implicit: Allows access to certain permissions by permitting an app to acquire or "inherit" permissions from another app with the same signing key (presumably by the same author).
So far, we only been dealing with "explicit capability leaks". I wanted to make sure of the difference, so I asked Dr. Jiang.Kassner: Would you please explain how the two types of leaks differ? Jiang: Sure! The explicit one exposes a service to any (untrusted) app so that a dangerous operation can be exercised without asking for the related permission.
The implicit one allows an app to inherit the permission from another app that is signed by the same developer certificate. In other words, the implicit one involves two apps from the same developer. The explicit one does not have this requirement.Kassner: I was curious as to what advantages one leak had over the other, from the perspective of a bad guy. Francis: As an attack vector, each capability leak has its place. Here are some pros and cons of each:
Explicit capability leak advantages:
- Your app never has to ask for the permission you wish to exploit.
- If the interface you are exploiting, exists on the ROM, the user can't get rid of the security hole easily.
- If the interface you are exploiting was included in the baseline release of Android, the hole likely exists on every device running that version of the OS.
Explicit capability leak disadvantages:
- You have to find the exposed intents in other apps to get your "foot in the door" so to speak.
- You don't control when the "door" is closed or even if a newer version of the component you are exploiting changes the behavior of your exploit entirely.
Implicit capability leak advantages:
- You know exactly how to call the exposed intent to exploit the permission you are looking for (since you wrote both apps).
- Because the attack relies solely on your software you can potentially run it on any version of Android providing you get the user to install your apps.
Implicit capability leak disadvantages:
- More than one of your apps has to be on the same device simultaneously.
- You must get the user to agree to at least one of your apps having the permission you wish to exploit.
- Users can almost always easily stop this type of vulnerability by simply uninstalling one or more of your components.
Dr. Jiang's team decided to automate the process of finding applications that allow another app to use granted permissions. I forgot to ask why, but the team called the tool -- Woodpecker:
"Woodpecker systematically analyzes each app on the phone to explore the reachability of a dangerous permission from a public, unguarded interface."Kassner: I wasn't clear about something in the definition. So, I asked Dr. Jiang; what does "reachability of a dangerous permission from a public, unguarded interface" mean? Jiang: Woodpecker analyzes each pre-loaded app and checks whether it has the permission (or capability) to exercise certain "dangerous" operations in Android (for example, sending an SMS message or deleting an app).
If such a pre-loaded app is identified, Woodpecker verifies whether the app defines a service that is not "guarded" and can be freely invoked by any untrusted app to exercise the "leaked" dangerous operation. If that is the case, we consider the permission to exercise the dangerous operation is leaked from the pre-loaded app to any untrusted app.Kassner: Another question Dr. Jiang. How does Woodpecker differentiate between explicit and implicit capability leaks? Jiang: When detecting explicit capability leaks, we focus on those apps that request permissions of interest in their manifest ﬁles. If an app has a sharedUserId in its manifest but does not request a certain (dangerous) permission, we also need to investigate the possibility of an implicit capability leak.
To detect implicit capability leaks, we employ a similar algorithm, but with changes to reﬂect a fundamental difference in focus. Speciﬁcally, explicit capability leak detection assumes the caller of an app's exposed API is malicious, while implicit capability leak detection assumes the app itself might be malicious.
Accordingly, instead of only starting from the well-deﬁned entry points in the explicit leak detection, there is a need to broaden the search to include the app's initialization.
Dr. Jiang mentioned, "permissions of interest". The following is the list he referred to:
- Access coarse location: Non-GPS radio
- Access fine location: GPS
- Call phone: Initiate a phone call (no user confirmation)
- Call privileged: Same as Call phone, but emergency phone numbers
- Camera: Access camera device
- Delete packages: Remove apps
- Install packages: Install apps
- Master clear: Remove user data (factory reset)
- Read phone state: Read phone-identifying info (IMEI)
- Reboot: Reboot the device
- Record audio: Access microphones
- Send SMS: Send SMS messages
- Shutdown: Power off the device
As you can see, gaining access to any of these features would be advantageous to those wanting to do digital harm.
Table 2 provides information on the vendor, phone model, Android version, and number of installed apps tested on each model of phone:
Table 3 displays the phone model, permissions tested, and the results from explicit and implicit leak test:
Here's what the paper said about the test results:
"We believe these results demonstrate that capability leaks constitute a tangible security weakness for many Android smartphones in the market today. Particularly, smartphones with more pre-loaded apps tend to be more likely to have explicit capability leaks."
The research team also notified the affected phone vendors:
"As of this writing, Motorola and Google have conﬁrmed the reported vulnerabilities in the affected phones. HTC and Samsung have been slow in responding to our reports/inquiries.
Though the uncovered capabilities leaks on the HTC and Samsung phones have not been conﬁrmed by their respective vendors, we have developed a test app to exercise and conﬁrm all the discovered (explicit) capability leaks on the affected phones."
I wanted to mention that the research team created a video demonstrating their capability leak research.
Always interested in potential solutions, I asked Dr. Jiang a few more questions.Kassner: I see "implicit leaks" being fixed by better inspection in Android Market. I do not see a way to solve the "explicit leak" issue you have discovered. Do you have any ideas? Jiang: Agreed. The best way to address the explicit leaks is from the vendors (e.g., by releasing a patch). To be honest, I don't see a good way for users to protect themselves, except not downloading and installing untrusted apps... Kassner: William Francis and I have been discussing the research team's findings. William had this to say:
"I don't know the iOS platform that well, but my understanding is that if I want to share a file between my app and yours, the 2 apps can't talk directly. I have to export the file (I'm speaking about in code, not something the user must do) to a common area.
Then iOS provides the API for another app to come along behind and import the file so it can be displayed. The result is that app 1 never talks directly to app 2 like it does on the Android platform. The advantage being that Apple gets their fingers on each request and can do some sanity checking for security exploits."
Is that something Android should consider?Jiang: I don't think so. The reason is that it is not consistent with the open principle behind the Android design.
I asked William what he thought could be done to rectify the two leaks. I used William' opinion on explicit capability leaks earlier. He made a comparison to iOS. As for the implicit capability leak, he offered some interesting advice:
"Implicit capability leaks aren't that worrisome. If they were, Google could easily fix the issue by changing their code-signing procedure from the developer to the app.
Meaning, as a developer I get one ‘digital signature' and apply it to all my apps. Thus all those apps share a set of permissions. If Google required me to create a new digital thumbprint for each app, then each of my apps would have its own signature and isolated permissions."
Capability leaks have the potential to be extremely harmful. But, as with most digital technology, being informed of what's possible and using caution when installing third-party apps should keep you safe.
Thanks to Dr. Jiang and the research team for shedding light on a major weakness in Android. And thank you, William, for explaining the inner workings of Android permissions.
Michael Kassner is currently a systems manager for an international company. Together with his son, he runs MKassner Net, a small IT publication consultancy.