Slashdot Mirror


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.

27 of 117 comments (clear)

  1. Nope by AmiMoJo · · Score: 5, Informative

    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.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    1. Re:Nope by Anonymous Coward · · Score: 2, Insightful

      Is that even a problem? When you download an app from the Play Store, it gives you a list of permissions that the app requests. You give it permission when you download the app. If Play does not list an app if your version of Android or phone does not support the feature, then that's potentially a problem, but an easy one to fix.

    2. Re:Nope by Rick+Zeman · · Score: 4, Insightful

      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.

    3. Re:Nope by Todd+Knarr · · Score: 5, Insightful

      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.

    4. Re:Nope by Bert64 · · Score: 3, Insightful

      On the other hand, the likelihood of this vulnerability actually being exploited is quite low for quite a few reasons... Primarily, because it requires that you first install a malicious app and then upgrade to a version of android which actually implements some new permissions...

      1, very few users ever update (or even have updates available)
      2, manufacturers will sometimes patch android but usually not provide updates to whole new versions and the small incremental patches wont introduce any new permissions
      3, now that this issue has been discovered its highly likely that future updates will contain a fix for it, and users are unlikely to update to a version that isnt the latest available for their particular handset, so *if* they can and do update they will be patching this issue anyway.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    5. Re:Nope by AmiMoJo · · Score: 2

      PROTIP: Never buy a carrier branded phone. It should be obvious to everyone by now, but apparently not.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    6. Re:Nope by AmiMoJo · · Score: 2

      Also, you would have to side-load any such app because Google won't allow apps that request system permissions on to Play.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    7. Re:Nope by alostpacket · · Score: 4, Informative

      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...)

      --
      PocketPermissions Android Permission Guide
  2. Researchers from Indiana University and Microsoft by MrKaos · · Score: 4, Funny

    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*.

    --
    My ism, it's full of beliefs.
  3. HMmm by Stumbles · · Score: 2, Insightful

    I expected better from Google.

    --
    My karma is not a Chameleon.
  4. Not a problem by sqlrob · · Score: 2

    This depends on upgrades. Carriers, upgrade?

    Hell, my wife and I are on different versions of Android, same carrier, same phone, both say they're fully up to date.

  5. Nevertheless, I do thank MS for pointing it out ! by Taco+Cowboy · · Score: 3, Interesting

    That is certainly an issue, but not the huge gaping security flaw the summary makes it sound like

    A security flaw is a security flaw. Whether or not it's a "gaping hole" it still can be exploited.

    For that, I sincerely thank Microsoft for so kindly pointed out that security flaw.

    No matter what's the ultimate intention / agenda of Microsoft in this case, with this security flaw exposed, let us hope that Google can do something to plug it, and make those "Billion Android Devices" just a little bit more safer.

    --
    Muchas Gracias, Señor Edward Snowden !
  6. Luckily, Android is never updated by mveloso · · Score: 5, Funny

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

  7. Re:Nevertheless, I do thank MS for pointing it out by Jane+Q.+Public · · Score: 3, Insightful

    "For that, I sincerely thank Microsoft for so kindly pointed out that security flaw."

    "Kindly"? Are you serious? There was nothing "kind" about it. It's anti-Android PR for Microsoft. Why the hell do you think Microsoft was involved with looking into it in the first place? The goodness of their hearts? Puh-leeeeeze.

  8. Wow by slapout · · Score: 4, Interesting

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

    --
    Coder's Stone: The programming language quick ref for iPad
    1. Re:Wow by symbolset · · Score: 2

      Just shy of a billion were sold last year alone.

      --
      Help stamp out iliturcy.
  9. Re:Nevertheless, I do thank MS for pointing it out by symbolset · · Score: 5, Interesting
    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.

    --
    Help stamp out iliturcy.
  10. Re:Nevertheless, I do thank MS for pointing it out by Chokolad · · Score: 3, Interesting

    "Kindly"? Are you serious? There was nothing "kind" about it. It's anti-Android PR for Microsoft. Why the hell do you think Microsoft was involved with looking into it in the first place? The goodness of their hearts? Puh-leeeeeze.

    What do you think of IE vulnerabilities found by Googlers ?

    http://www.google.com/about/ap...

  11. In other news... by Ukab+the+Great · · Score: 2

    That there are 3,500 customized versions of Android developed by handset makers and carriers is really a news story unto itself.

    1. Re:In other news... by AmiMoJo · · Score: 2

      Counting the way they do you could say that there are 10,000+ versions of Windows out there. Every random OEM that loads up some crapware or changes the wallpaper counts as a new custom version to them. Of course in reality it makes little difference to developers or users (updates are provided by Google, the same way as "custom" versions of Windows still get updates from Microsoft).

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  12. Re:Nevertheless, I do thank MS for pointing it out by gerardrj · · Score: 4, Insightful

    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.

    --
    Article X: The powers not delegated... by the Constitution...are reserved...to the people
  13. Re:Nevertheless, I do thank MS for pointing it out by Jane+Q.+Public · · Score: 2

    "What do you think of IE vulnerabilities found by Googlers ?"

    I wasn't saying Microsoft is any worse. Just that they weren't doing it for the sake of charity.

  14. Re:Nevertheless, I do thank MS for pointing it out by Jane+Q.+Public · · Score: 4, Insightful

    "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.

  15. Re:Nevertheless, I do thank MS for pointing it out by Sun · · Score: 2

    As long as the research is valid and the conclusions correctly presented (which, in this case, they do not seem to have been), I don't care for the motive.

    Shachar

  16. Android has an even bigger problem with priveleges by Srin+Tuar · · Score: 5, Insightful

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

    This should be the most basic feature.

  17. Re:Nevertheless, I do thank MS for pointing it out by swillden · · Score: 2

    As long as the research is valid and the conclusions correctly presented (which, in this case, they do not seem to have been), I don't care for the motive.

    No argument. The research seems decent and worthwhile. The tone of the press release is what's eye-rollingly ridiculous. This is a minor security UI deficiency, but they're selling it as a "privilege escalation", which is normally understood to mean the ability to break out of the sandbox at least, and usually implies root access.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  18. Cyanogenmod Privacy Guard by emil · · Score: 4, Interesting
    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.