



Combating fragmentation with a single code base

and back-compatibility. That is, you can write an app that uses new APIs, but runs on old systems, by testing for the API level and not calling unimplemented features. This enables developers to keep a single code-base for many versions of Android.



However, old Android versions can't see their own future. That means that when new permissions are introduced, it is possible that an app created their own permissions with the same name. And therein is the basis for a vulnerability identified in this paper by



A key set of features of Android is good forwardback-compatibility. That is, you can write an app that uses new APIs, but runs on old systems, by testing for the API level and not calling unimplemented features. This enables developers to keep a single code-base for many versions of Android.However, old Android versions can't see their own future. That means that when new permissions are introduced, it is possible that an app created their own permissions with the same name. And therein is the basis for a vulnerability identified in this paper by Indiana University and Microsoft Labs researchers

Bad Android!

The result is an app that never asked for a permission, but got one anyway. That's bad! It's not just bad implementation bad, it's design-flaw bad. On the other hand, there are a fairly narrow set of cases where this vulnerability can be exploited in practice and there is a workaround: If you uninstall and re-install apps, you will be presented with the permissions the app requests.





There is also a telltale that marks apps that are attempting to do this:





For example, the app can deﬁne a new system permission such as permission.ADD_VOICEMAIL on Android 2.3.6, which is to be added on 4.0.4. It can also use the shared user ID (UID) [17] (a string speciﬁed within an app’s manifest ﬁle) of a new system app on 4.0.4, its package name and other attributes. Since these privileges and

attributes do not exist in the old system (2.3.6 in the example), the malicious app can silently acquire them (self-deﬁned permission, shared UID and package name, etc.). When the system is being updated to the new one, the Pileup ﬂaws within the new Package Manager will be automatically exploited. Consequently, such an app can stealthily obtain related system privileges, resources or capabilities.





That means that in almost all cases, apps that escalate permissions this way intended to do so. That means Google can enhance Bouncer, their system for automatically detecting badware in the app store, to automatically detect apps that use this exploit. But it also makes the bug worse:





In the above example, once the phone is upgraded to 4.0.4, the app immediately gets permission.ADD_VOICEMAIL without the user’s consent and even becomes its owner, capable of setting its protection level and description. Also, the preempted shared UID enables the malicious app to substitute for system apps such as Google Calendar, and the package name trick was found to work on the Android browser, allowing the malicious app to contaminate its cookies, cache, security conﬁgurations and bookmarks, etc.





Now that's bad! This is one of the most interesting Android bugs I have yet encountered.





Permissions need a bigger fix

In addition to a fix, I think this bug should prompt a change in how app permissions are handled. I believe they should be revocable on an individual basis. That would help thwart "permission creep" as well as reducing the severity of bugs like this one.

This might not be the single most interesting bug in all of Android, but out of the ones I have encountered or heard of, it definitely caught my attention.