About the "Pileup" Vulnerabilities

An academic paper made the news recently regarding a new round of vulnerabilities in Android. This paper’s focus was distinctive, though, in that they examined vulnerabilities that occur due to OS upgrades.

. . .

Yes, some Android devices do get their OS upgraded.

. . .

No, I’m serious, they do. Stop laughing.

Some of the vulnerabilities are a firmware-centered variant of the problem I pointed out recently with custom permissions. In this case, though, the permissions are system permissions that will be defined in the future.

For example, suppose that, by examining an Android 5.0 device or the published source code, we determined that Android 5.0 added new CONTROL_SEA_BASS and ATTACH_FRICKIN_LASER_BEAMS permissions. We could publish an app that requests these permissions. On older Android devices, we would not be able to use the permissions to do anything. But, for those devices that have our app and get upgraded to Android 5.0, we would automatically get the permissions, without user knowledge… even system or signature-level permissions.

(and one would certainly hope that these would be system-level permissions – imagine the damage that could be wrought with CONTROL_SEA_BASS!)

There are other variants on the theme, where the app can arrange to get things that it ordinarily could not, because of the particular algorithms and processes used when applying an OS upgrade.

From my reading of the paper, little of this affects app developers specifically. If anything, pre-installed apps (e.g., AOSP, Google app, manufacturer apps) appear to be at greater risk than ordinary SDK apps. Users are at risk, and while the frequency of possible attack is low (since OS upgrades are at best infrequent), the possible damage is substantial.

If, in your reading of the paper, you can think of ways that ordinary app developers might be affected by Pileup flaws, drop me a line.