Vulnerabilities with Custom Permissions

Mark Carter posted a comment on one of my StackOverflow answers. Based on his analysis, my own, and discussion of this with “Justin Case”, an Android security researcher, it appears that there’s been a limitation to how custom permissions work in Android, one that can leave apps that use them vulnerable to attack.

Specifically, it appears that Android works on a “first one in wins” strategy, and developers need to be aware of what this means.

The Synopsis

If two apps define the same custom permission (via the <permission> element in the manifest, with the same android:name value), whichever app is installed first is the one whose definition is used.

On the one hand, this is not terribly surprising. “First one in wins” is a common approach to handling duplicate definitions of things.

However, unlike duplicate package names or duplicate ContentProvider authorities — where the installation fails due to the duplicate — installation proceeeds in this case. That too is not terribly surprising, as this behavior can be rather useful in cases where the installation order of apps is not known in advance.

However, it does open up significant risks. An attacker can gain access to a defender’s secured components simply by:

• Declaring the same custom permission,
• Requesting that custom permission via <uses-permission>, and
• Being installed first

Android never informs the user that the attacker requested this permission, and so the user is oblivious to the fact that the attacker has access to their data in the defender’s app (to the extent offered via this permission).

Worse, the attacker can decide to have its edition of the custom permission have a normal android:protectionLevel, and this supersedes any signature android:protectionLevel that may be established by the defender. The attacker not only can obtain this permission silently, but it does not need to have the matching signing key.

The Mea Culpa

I should have realized this a couple of years ago, at least. I did some research for determining how apps employing custom permissions can support arbitary installation order. My solution is to define the same permission in both apps, and that is precisely the scenario that an attacker would use. I was focused on enabling communications between apps and failed to do broader research about ensuring that there were no related vulnerabilities. I am deeply sorry that I failed to do this back then.

This issue is also apparently known about in Android security circles. The Android Security team has stated to methat this is “working as intended”.

I am blogging about it here as I suspect that it is not widely known among Android developers, and it needs to be better known. I have already notified the developers of one “brand name” Android app about the issue (since I had proved that they were vulnerable as part of my testing), and I am sure that there are countless others who use custom permissions and are unaware of the problem.

What Now?

You can read a more in-depth write-up of my analysis of this issue.

That paper is in the repository of a new CWAC library, CWAC-Security, where I have a PermissionUtils class that can help you detect, on first run of your app, if some other app has already defined one of your custom permissions. You can then take steps if needed (e.g., the app is not on some whitelist), to notify the user about the other apps and perhaps to record this information yourself to perhaps identify attackers.

I have also filed an enhancement request to try to improve Android’s handling of custom permissions. However, b.android.com issues can rapidly become a cesspool. Please do not post “me too!” or “Google is teh evil!” comments on the issue, as those will merely make it less likely that this will be addressed. If you have additional analysis, thoughts on implementations, or the like, those would be fine comments, if you wanted.

If you find flaws in my analysis, or if you find flaws (or have enhancement suggestions) related to CWAC-Security, feel free to file an issue. If you find additional vulnerabilities in this area, contact the Android Security team, or contact me if you prefer. If you have general development questions in this area, post to StackOverflow in the android tag or use your favorite Android developer support site.

I would once again like to thank Mark Carter and “Justin Case” for their assistance with this issue.