One Billion Android Devices Open To Privilege Escalation

msm1267 (2804139) writes "The first deep look into the security of the Android patch installation process, specifically its Package Management Service (PMS), has revealed a weakness that puts potentially every Android device at risk for privilege escalation attacks. Researchers from Indiana University and Microsoft published a paper that describes a new set of Android vulnerabilities they call Pileup flaws, and also introduces a new scanner called SecUP that detects malicious apps already on a device lying in wait for elevated privileges. The vulnerability occurs in the way PMS handles updates to the myriad flavors of Android in circulation today. The researchers say PMS improperly vets apps on lower versions of Android that request OS or app privileges that may not exist on the older Android version, but are granted automatically once the system is updated.

The researchers said they found a half-dozen different Pileup flaws within Android's Package Management Service, and confirmed those vulnerabilities are present in all Android Open Source Project versions and more than 3,500 customized versions of Android developed by handset makers and carriers; more than one billion Android devices are likely impacted, they said." Handily enough, the original paper is not paywalled.

Comments

Nope

[AmiMoJo]

What the summary fails to explain properly is that this vulnerability only works with permissions that are new when the device gets an OS update. Say you install an app and it asks for permission to use NFC, but your device's OS is old and doesn't support NFC (pre 4.0 I think). You install it anyway. Then you upgrade the OS and now it supports NFC. The app then gets the NFC permission without any further prompts or warning to the user.

That is certainly an issue, but not the huge gaping security flaw the summary makes it sound like. Apps can only ask for normal permissions that the OS offers, not bypass security or the sandbox. It's basically a UI issue.

Re:Nope

[Rick Zeman]

What the summary fails to explain properly is that this vulnerability only works with permissions that are new when the device gets an OS update. Say you install an app and it asks for permission to use NFC, but your device's OS is old and doesn't support NFC (pre 4.0 I think). You install it anyway. Then you upgrade the OS and now it supports NFC. The app then gets the NFC permission without any further prompts or warning to the user.

That is certainly an issue, but not the huge gaping security flaw the summary makes it sound like. Apps can only ask for normal permissions that the OS offers, not bypass security or the sandbox. It's basically a UI issue.

Yeah, and since the carriers update Android devices so infrequently the threat exposure is more theoretical than practical.

Re:Nope

[Todd Knarr]

The problem here is that the permissions system goes beyond just ordinary user permissions. The system itself uses permissions to control which parts of the system can do what, and those permissions are normally only available to system components (trying to install an app that asks for those permissions results in the app being rejected because it doesn't qualify to get those permissions). For instance, the "Across_users" permission was added to Android 4.2, and allows system components to break through the normal restrictions that separate different users in the system. An app with this permission can reach out and directly affect everything on the phone, not just the things that belong to it. It's restricted to Android system components only. But if I install an app that asks for it on an Android 4.0 device, the app will install without any warnings. If the device is then upgraded to 4.2, the app will silently get the "Across_users" permission activated. So now we have a user-installed app which has a permission that it could never legitimately have that lets it bypass security and the sandbox, and the user will be unaware of the problem. It's very definitely NOT just a UI issue.

In the Unix world it'd be equivalent to finding an other-writable directory sitting in the root user's PATH, and in that directory are executables named "ls", "cat" and so on. It's the kind of thing that'd make a security admin excrete cinder blocks at velocities sufficient to have them achieving high orbit, ceilings nonwithstanding.

Re:Nope

[alostpacket]

I wonder, though. When you buy a new Android phone and sign in to Play, it downloads (or at least offers to) all the apps you had on your old phone. Does the same thing happen there

No, this particular exploit requires the malicious app be on a phone prior to an OS update. Additionally these apps would never* make it on the Play store as they have detectable characteristics (such as trying to use the same "Shared UID" of another app). In order to upload an app with the same Shared UID, you would need the same keystore to sign your app. Basically the way this bug works is exploiting the reverse of how the package manager grants precedence. The package manager give precedence to what is on the device first. So anything "updated" from the Play store, even if they spoofed the Shared UID and signature, would fail to install. The bug is that an app can "steal" the ability to control the permission completely, AND install itself or block the install of the legit version of an app.

So TL;DR: This definitely is a rather nasty privilege escalation bug in the package manager (if the paper is correct and I am reading it correctly), but one would likely need to side-load (or use a different app store) the malicious app prior to an OS update to get caught by it.

Agreed about permissions in general though. Personally I try not to give out contacts to any app unless they happen to be a type of "contact manager/replacement". Most apps can request a user use the default "contact picker" to add a contact, or share, or the like. No permission is required for this. The only reason apps request this is to prefill those "share with a friend" fields and to spam. This is similar to READ_PHONE_STATE, there are few legit reasons for an app to need this anymore. Apps can launch the dialer and prefill the number sans the permission, just not complete the call. They also have other ways to generate a UUID for the device without the IMEI, or the other info provided by READ_PHONE_STATE.

The USB storage permissions are antiquated, but not as sensitive. Apps do have private storage but this used to be quite limited in the earlier days of Android. The Nexus S was one of the first to come with a single, large internal storage (although even that was still partitioned). Prior to that you had a limited protected storage and an SD card. Nowadays they are adding better "Read" file permissions.

Finally, I think much of this stuff could be requested at time-of-use, rather than install. But they have to balance the "Are you sure you want to allow X?" disaster that was Windows UAC vs. sensible permissions. It is not as easy as it looks.

* (Well maybe not never, but very close to never...)

Researchers from Indiana University and Microsoft

[MrKaos]

Handily enough, the original paper is not paywalled.

Wow, a freeby from Microsoft, how incredibly generous. Google will probably thank them for pointing it out. Isn't it nice how everybody just, *gets along*.

Luckily, Android is never updated

[mveloso]

Luckily for most Android users Android is almost never updated, so in real life there's no real vulnerability.

Wow

[slapout]

There are one billion Android devices? That's awesome!

Re:Nevertheless, I do thank MS for pointing it out

[symbolset]

The source of malware still has to get you to install their app and then update your Android. And it's only a problem if you didn't already assume that when you gave the app that permission it would gain it when available. The risk is way overstated. If this is the mud Microsoft can sling, I find that comforting.

Now let's talk about that last patch batch where IE couldn't even safely display a JPEG in any currently supported version on any version of Windows.

Re:Nevertheless, I do thank MS for pointing it out

[gerardrj]

Considering the amount of money that Microsoft makes in patent licensing fees from Android I don't know how they could have any financial reason to want Android to go away. At the moment I suspect that Microsoft makes more money from Android than it does Windows Phone.

Re:Nevertheless, I do thank MS for pointing it out

[Jane Q. Public]

"Considering the amount of money that Microsoft makes in patent licensing fees from Android I don't know how they could have any financial reason to want Android to go away. At the moment I suspect that Microsoft makes more money from Android than it does Windows Phone."

That last bit is exactly why they want Android to go away. They don't make nearly as much money on Android as they'd make if all those same phones were Windows. Every Windows phone they can sell in place of an Android phone is more money in their pockets.

Sure, they'll make money off of Android where they can. But they'd rather it simply wasn't there.

Android has an even bigger problem with priveleges

[Srin Tuar]

In that it still doesnt allow line-item veto of app priveleges.

This should be the most basic feature.

Cyanogenmod Privacy Guard

[emil]

http://wiki.cyanogenmod.org/w/...

Using Privacy Guard, I can see that Facebook has attempted to read my contact list 94 times. These attempts were blocked.