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.
If two apps define the same custom permission (via the
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
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
- 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
android:protectionLevel, and this supersedes any
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.
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
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
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.
The AndroidX Tech site contains source code, transitive dependency details, and much more for Google’s