Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Android Cellphones Google Handhelds IBM

Severe Deserialization Vulnerabilities Found In Android, 3rd Party Android SDKs 105

Posted by timothy from the dag-nab-it-not-again dept.
An anonymous reader writes: Closely behind the discoveries of the Stagefright flaw, the hole in Android's mediaserver service that can put devices into a coma, and the Certifi-gate bug, comes that of an Android serialization vulnerability that affects Android versions 4.3 to 5.1 (i.e. over 55 percent of all Android phones). The bug (CVE-2015-3825), discovered by IBM's X-Force Application Security Research Team in the OpenSSLX509Certificate class in the Android platform, can be used to turn malicious apps with no privileges into "super" apps that will allow cyber attackers to thoroughly "own" the victim's device. In-depth technical details about the vulnerabilities are available in this paper the researchers are set to present at USENIX WOOT '15.
This discussion has been archived. No new comments can be posted.

Severe Deserialization Vulnerabilities Found In Android, 3rd Party Android SDKs More

Severe Deserialization Vulnerabilities Found In Android, 3rd Party Android SDKs

Comments Filter:
  • Google has already patched the SDKs, but I think any apps made with them have to be updated as well.

    • In that case is there any way to patch the OS? Trusting every application vendor to update their application is risky. The major vendors will, but the smaller ones may never update their apps again, even though some people are still using them.

      • The article is a little bit ambiguous; it says Google's already patched OpenSSL, so I'm guessing if your device still receives updates from your carrier, then you're safe (if not, you should have already flashed CyanogenMod). The apps only need to be updated for those Android devices that will go unpatched.

        • The article is a little bit ambiguous; it says Google's already patched OpenSSL, so I'm guessing if your device still receives updates from your carrier, then you're safe

          So, IOW, RUN FOR THE HILLS!!!

      • Re: (Score:2)

        by AmiMoJo ( 196126 )

        There is no need for them to patch the OS to mitigate this vulnerability, in actual fact. They simply add it to one of the things to look for when they scan apps that are being installed on Android devices. This feature is enabled by default, even for apps installed from sources other than the Play store.

        So really to fall victim to this you would have to go far out of your way to be dumb. Enable installing apps from other sources, disable scanning of new apps before installation and then install a malicious

        • So really to fall victim to this you would have to go far out of your way to be dumb. Enable installing apps from other sources

          So, IOW, you have to submit to a "Walled Garden", right?

          Haaaa Hahahahhahahahahahaha!!!!!

          And tell me truthfully, if this Article was about iOS instead of Android, would you REALLY be downplaying the danger here?

          Thought so.

          • So, IOW, you have to submit to a "Walled Garden", right?

            Ummm, no? You have to actively turn off known app vulnerability scans when you sideload. Even if Joe Shmoe user finds out how to sideload, most will just tap on the big OK let google scan this app for vulnerabilities.

            Plus this is about unrooted phones. Hows that sideloading going for non jail-broken iOS devices?

            And tell me truthfully, if this Article was about iOS instead of Android, would you REALLY be downplaying the danger here?

            Nope, since everything on iOS _has_ to go through the app store, and can't be sideloaded ( unless you jailbreak... meaning there was ALREADY a security vulnerability ) it wouldn't be downplayed since

            • Ummm, no? You have to actively turn off known app vulnerability scans when you sideload. Even if Joe Shmoe user finds out how to sideload, most will just tap on the big OK let google scan this app for vulnerabilities.

              So, as I said, the ONLY way to be even semi-secure with Android is to only download "curated" Apps. Anything else relies on the User to not be too anxious to see the new Hello Kitty wallpaper.

              Plus this is about unrooted phones. Hows that sideloading going for non jail-broken iOS devices?

              Fortunately, most SANE iOS Users don't jailbreak. So, my question to you is "How's that sideloading going for Android Devices?"

              Nope, since everything on iOS _has_ to go through the app store, and can't be sideloaded ( unless you jailbreak... meaning there was ALREADY a security vulnerability ) it wouldn't be downplayed since the app was ALREADY said to be safe from a security scan / audit. If iOS allowed sideloading, AND Apple scanned sideloaded apps like Google, then it would be no different.

              LOL! That logic is SO circular that you made me dizzy! What the HELL are you trying to doublespeak?!?

              • the ONLY way to be even semi-secure with Android is to only download "curated" Apps

                True, but Android lets the user choose more than one curator. Other established curators include Amazon and F-Droid.

                • the ONLY way to be even semi-secure with Android is to only download "curated" Apps

                  True, but Android lets the user choose more than one curator. Other established curators include Amazon and F-Droid.

                  So, you really trust Amazon, let-alone F-Droid, to properly "vet" Apps?

                  Heck, even Google has let several (and I mean SEVERAL) malware-infested Apps exist on the Play Store. There have been a COUPLE (and I mean a COUPLE) of (now deleted) infected iOS Apps; but nothing compared to Android, even on the "Curated" sites.

                  • Re: (Score:2)

                    by tepples ( 727027 )

                    F-Droid's Inclusion Policy [f-droid.org] states that it distributes only apps whose source code is in a publicly readable version control repository and distributed under a free software license. Its Inclusion How-To [f-droid.org] states that all executables come from its own build farm and that new apps are suggested by forum users. This would at least give other forum users a chance to review apps' source code for obvious "anti-features". Or are you arguing based on the same phenomenon that caused OpenSSL defects not to be detected

            • Re: (Score:2)

              by wbo ( 1172247 )

              Nope, since everything on iOS _has_ to go through the app store, and can't be sideloaded

              This is not really true. IOS developers can sideload any app they wish as long as they sign it with their developer key first. You don't have to have access to the source code either, the code signing tool will happily let you sign any binary you want.

              A developer key currently costs $99/year which is certainly not free but it is low enough that most people could afford it if they really want to sideload apps legit

    • The bug (CVE-2015-3825), discovered by IBMâ(TM)s X-Force Application Security Research Team in the OpenSSLX509Certificate

      I wonder what sort of security analysis they used, I guess something like grep -r openssl * -lt 1 || echo "Security vuln found!" would do it.

    • Re:Already patched (Score:5, Informative)

      by swillden ( 191260 ) <shawn-ds@willden.org> on Tuesday August 11, 2015 @10:08AM (#50293515) Journal

      Google has already patched the SDKs, but I think any apps made with them have to be updated as well.

      (Android security team member here.)

      There's a platform-level fix which involves both Google Play Services changes and core OS changes. The Google Play Services changes were pushed out in early June. The core OS changes were pushed to Nexus devices in last week's update, and other OEMs have had the fix (including backported versions of the fix for older Android versions) since June and should be delivering it with their own updates.

      • Re:Already patched (Score:5, Interesting)

        by flopsquad ( 3518045 ) on Tuesday August 11, 2015 @11:07AM (#50294051)
        Serious question for an Android security team member:

        With three major, ecosystem-wide exploits published just in the last week or so, why can I still not get root on my S6 Active? My (limited) understanding is that attackers could own me and a billion other people six ways from Sunday, but when it comes to just owning my own phone... ?

        • Wrong folks to ask (Score:4, Interesting)

          by ThatsNotPudding ( 1045640 ) on Tuesday August 11, 2015 @12:22PM (#50294703)
          This should be a question for the FCC to ask all the US carriers. Failure to push OS security updates should result in massive fines against all of them, not just the usual level of 'spare change in the corner office couch cushions' type, as these vulnerabilities will sooner or later affect life and limb.

          If you whine and slow-play some BS about making sure it won't harm your precious networks, okay. But the fines will be imposed and continue to increase until the all the patches are truly pushed out.

          Carriers, either push out the security updates to all affected phones, or release unlockers to allow your customers to defend themselves; there should be no other options given to you.

          • Re: (Score:2)

            by Krojack ( 575051 )

            This is what I keep pushing for. Manufactures and carriers should have 30 days AFTER Google patches to push out the fixes for ALL security vulnerabilities. Those that fail get a fine for each day after 30 days they are late. Samsung is still working on Android 5.0.2 for my old Note 2 and my Note 10.1 tablet. Fucking 5.0 was released over 13 month ago.

            I say as long as Google is still patching versions of Android then manufactures should be required to push out those versions to their devices.

          • Carriers, either push out the security updates to all affected phones, or release unlockers to allow your customers to defend themselves; there should be no other options given to you.

            Historically, there has been a reason for the way carriers are with respect to software updates. They aren't actually evil you know - they're staffed by engineers, just like most of us.

            The issue is that before Android and iOS came along, the vast majority of all phones had firmware updates rarely or at all. Whats more, most ph

            • Re: (Score:2)

              by afidel ( 530433 )

              Then they need to take some of their massive profits (in dollar terms) and hire some more QA engineers so they can test updates in a timely manner. It shouldn't take 6+ months after a manufacturer has released an update for it to hit my device, it should be days or weeks at most.

              • And if you want your baby quicker, you just need more women.

                I'm sure that in some cases staffing actually is an issue, but I know that in many cases it's really not the problem... and in some the problem is that stuff just takes time, and it's really not possible to go faster. For example, you do some testing, find a problem and then can't usefully test all of the other stuff around that problem until it's fixed. Then you find and fix another problem, which uncovers a subtle, previously-hidden flaw elsewh

                • Re: (Score:2)

                  by afidel ( 530433 )

                  Sorry, you don't get time. Your own companies security folks are only giving 3rd parties 90+- days from communications to public disclosure of vulnerabilities to produce, test, and release a patch to their users, if you think anyone is going to give you any more is deluded so you have to have your stuff together enough that you can turn a security bug into an end user distributed patch *available through the carriers* in ~90 days. That's the cold hard reality. If you can't do it then something has to change

                  • 90 days is enough time. You said "days or weeks at most". That is not feasible.

                    • Re: (Score:2)

                      by afidel ( 530433 )

                      I also said *after a manufacturer has released an update*, the process of doing the QA at the telecom level shouldn't take a significant percentage of the 90 days.

                    • I also said *after a manufacturer has released an update*, the process of doing the QA at the telecom level shouldn't take a significant percentage of the 90 days.

                      Okay, I stand corrected. I agree with that... at least if the OEM did a decent job. A little while ago talked to the heads of QA of two major US MNOs, who both commented that they also thought that's how it should be, but experience has shown them that they can't trust the OEMs not to screw things up, so they have to do really thorough QA.

                      FWIW, a bunch of OEMs at the same meeting also agreed that things need to change, so I'm hopeful that over the next couple of years they will. Google is trying to push t

          • Comment removed based on user account deletion

        • With three major, ecosystem-wide exploits published just in the last week or so, why can I still not get root on my S6 Active?

          Honestly... at least part of it is because the exploits are not nearly as serious as described. Stagefright appears to be unexploitable on a device with proper ASLR, which your S6 has. This deserialization vuln isn't sufficient to get root (though perhaps it could be chained with another exploit). The pingpong vuln should be enough to get you persistent root... but by the time someone has packaged a nice tool to do it, Samsung will probably have pushed an update.

          If you really want to root your device, yo

          • Oh, forgot to mention the "certifi-gate" vuln. That one is also overrated. It doesn't give root (though perhaps could be a good start to an exploit chain) and depends on your OEM having done something dumb (I don't recall if Samsung did).

          • A very large portion of rooted Androids with SELinux do not "setenforce 0", and I've not seen it recommended for ages.

            As for handicapping the Android security model, I am reminded of a quote about safety being a tyrant's tool...

            • Hence the GP's closing sentence. You've been informed; the rest is up to you.

            • I am reminded of a quote about safety being a tyrant's tool...

              Where's the tyrant? I'm telling you go nuts if you want to do it, just don't come whining if it costs you.

          • Thanks for the explanation, +5 Informative.

            I'm still getting familiar with the Android world, having recently stormed away from iOS (frustrating lack of control over the OS, even when jailbroken). I was headed for freedom, baby! So imagine my surprise when my new Android phone is locked down tighter than my old Apple phone. At least that I could jailbreak and it never had forced OTA updates (wtf?).

            I've been keeping an eye out for a workable root solution. Tumbleweeds. (And pingpong has an expirat

        • With three major, ecosystem-wide exploits published just in the last week or so, why can I still not get root on my S6 Active?

          Because that'd make the Android security model the same as the Windows security model. Which is, you know, a failure.

          "Application 'Samsung Totally Official Important Update' wants root: approve/deny"

          What could possibly go wrong?

          Devices that allow firmware reflashing like the Nexus devices are sold on the understanding that only power users and OS enthusiasts will ever find the hidde

        • Comment removed based on user account deletion
          • Good point, it'd be much harder to do a bunch of nasty stuff on a feature phone that just can't do much other than make phone calls. I use so many apps and smartphone features on a daily basis that it'd be tough to go back, though.

            But you're right, it is just a matter of wanting my device to work exactly how I want it to, and fiddle with the guts. And not compromise on any other features (waterproofing notwithstanding... that has been less effective than advertised).

        • why can I still not get root on my S6 Active

          i suggest you ask yourself why you purchased a samsung device? are you really asking a google employee why samsung doesn't allow (or make it obvious) for you to root your phone?

          • Nah, just trying to get a semi-technical question that had been bugging me, answered by a poster more knowledgeable than I. With all the scary exploits getting press, I was curious why no one had harnessed one for our benefit. And GP answered--none of them are as scary as they'd need to be in order to do that.

  • holy crap (Score:2, Interesting)

    by Anonymous Coward

    this is getting silly. I'm gonna go get an old ass nokia non-smart phone and just be happy.

  • Perhaps someone with more Java/Android experience can elaborate but my quick read on serialization leads me to believe that this is a flaw in Java itself and that per the below, while steps can be taken to mitigate the risk, it can't be eliminated.

    While the patches xed the specic instances that
    we had found, we feel that a general problem de-
    serves a general mitigation, reducing the impact of
    such serialization attacks. Since Bundles are very
    common in Android’s Inter-Process Communication,
    we suggest cha

    • According to the article:

      "Further analysis showed that many of the SDKs were vulnerable due to weak code generated by SWIG, an interoperability tool that connects C/C++ with variety of languages, when fed with some bad configuration given by the developer." https://www.usenix.org/confere... [usenix.org]

      So it doesn't sound like Java.

    • Deserialization vulnerabilities are a general problem with any runtime platform that supports ser/deser of in-memory objects to and from disk (or the network, or anywhere else you can deserialize to, e.g. stdout).

      There isn't a whole lot the runtime itself can do to protect your code from deser exploits, since it doesn't know about the internal structure of your object data. Built-in support for ser/deser is pretty barebones and generic; if not customized, it can often serialize things in a way that is gross

    • It's Java, but made worse by the Android ecosystem. Specifically, Android uses Serialization to pass data between mutually non-trusting applications (where the more common case is to pass objects between instances of the same desktop application, or between client/server both written by the same author). Also, the vulnerability arises where serialized objects have fields containing native pointers that aren't marked "transient" or otherwise sanity-checked. Java doesn't have a "native pointer type", but o

    • Re:Android or is it Java? (Score:4, Informative)

      by IamTheRealMike ( 537420 ) on Tuesday August 11, 2015 @11:58AM (#50294531)

      It's not exactly a flaw in Java. All their exploits rely on finding bits of Java that call into C/C++ code because that's the only way to break out of the memory-safe type system constraints. If Android had used a pure Java SSL implementation (like Java SE does) instead of wrapping OpenSSL, this issue would not have existed, as the only class in the entire framework that was vulnerable to this was one that wrapped a native C structure and the issue worked through manipulation of C/C++ memory management code.

      So this boils down to "native code is dangerous". Which we already knew. Stagefright was just the same: the parts of Android written in Java rarely have security bugs, and the most serious issues invariably crop up in the C/C++ components.

      However. One could argue that the Java serialization mechanism makes it a little bit too easy to accidentally de/serialise things that you didn't mean to. As the paper notes, it is an opt out system in which you tag fields which should not be loaded/unloaded, rather than the other way around. This makes it easy to serialise too much. If you then deserialise a native pointer which is freed inside a finaliser ..... bang. So we can imagine that Java could make it harder to commit this mistake if it had a better designed serialisation system. Nobody likes Java serialisation: it's one of the oldest parts of the platform and dates back to the early 90s, before anyone realised the subtle security implications of deserialising malicious object graphs. But of course it cannot be removed for backwards compatibility reasons. Perhaps the Android tools should warn about usage of it, though.

      And the design of the Android APIs also comes under fire ..... they will happily deserialise objects that the developer did not expect. If they simply asked the developer "what is it you expect this bundle to contain" and then did some checks before actually deserialising the objects, the whole issue could have been avoided as well.

      So there are multiple places where things can be tightened here.

    • Re: (Score:1)

      by EStrat ( 174854 )

      "...so less apps..."
      Stannis, you take this one [youtube.com]

  • I realize this needs to be patched, however just what are the odds of this happening? Apple OSes, linux, Windows, bds's all have various issues. They are routinely taken care of. My guess is the odds are extremely low if not zero. Google probably pays these kind of folks for discoveries like this.

    • Re:Re serialization issue (Score:5, Insightful)

      by 0123456 ( 636235 ) on Tuesday August 11, 2015 @09:18AM (#50293053)

      The problem is that Android issues aren't 'routinely taken care of'. Most Android devices will never see a fix for this, because manufacturers have abandoned them and carriers want you to upgrade to a new phone.

      I almost wonder whether Google are encouraging people to publicize Android vulnerabilities so they can say 'look, this isn't working, we need to be able to push updates to phones ourselves'. They have to do that if Android has any future.

      • I almost wonder whether Google are encouraging people to publicize Android vulnerabilities so they can say 'look, this isn't working, we need to be able to push updates to phones ourselves'.

        If that was really what they wanted to do, they would've designed it that way in the first place. Windows manages to update itself across a wide variety of hardware without involvement from the manufacturers.

        • Re: (Score:1)

          by Anonymous Coward

          I almost wonder whether Google are encouraging people to publicize Android vulnerabilities so they can say 'look, this isn't working, we need to be able to push updates to phones ourselves'.

          If that was really what they wanted to do, they would've designed it that way in the first place. Windows manages to update itself across a wide variety of hardware without involvement from the manufacturers.

          Windows isn't open source and Dell doesn't take that source and heavily modify it before passing it on to Best Buy who adds their own changes before installing it on a machine and selling it to you. This is essentially how the Android ecosystem works: Google writes the base system, OEMs modify it, carriers modify it some more. The exception to this is Nexus devices, whose hardware (and some firmware) comes from OEMs, but the software is stock Android, and is updated by Google.

          • Re: (Score:1)

            by Anonymous Coward

            What now?
            Haven't we been told for years that Open Source is superior to the closed source because everyone can find vulnerabilities and even if some problem is found the patch is found and distributed faster, unlike closed source? And now you claim that the problem with Android is that it can't be patched because it's Open Source?

            • It's not the open source that's a problem, it's the OEM customization. But I'm running the Cyanogenmod 12.1 ROM on my 1st gen Moto G, and all or most of these vulnerabilities were patched on my phone long ago. So to those who are technically inclined enough to load up custom ROMs (easier on some phones than others), the open source nature of Android does help.

        • Re: (Score:2)

          by swb ( 14022 )

          They wanted hardware manufacturer adoption and carrier adoption without the dealmaking Apple did with AT&T to get them to allow a device they couldn't modify with carrier crapware.

          I wonder if they know regret making that Faustian bargain given the noise level about carrier skins, lack of updates, etc.

        • I almost wonder whether Google are encouraging people to publicize Android vulnerabilities so they can say 'look, this isn't working, we need to be able to push updates to phones ourselves'.

          If that was really what they wanted to do, they would've designed it that way in the first place. Windows manages to update itself across a wide variety of hardware without involvement from the manufacturers.

          Windows is also highly limited on the hardware it can run on, and very restricted in what the manufacturers can do to improve the OS. One of the reasons Android is as widespread and good as it is is that there was alot of freedom in the early days for improvements to be made by manufacturers, which eventually got folded into the main stock builds.

          Android seriously needs to focus on security updates now, but to lock down the manufacturers years ago would have seriously restricted its development.

      • I almost wonder whether Google are encouraging people to publicize Android vulnerabilities so they can say 'look, this isn't working, we need to be able to push updates to phones ourselves'. They have to do that if Android has any future.

        Google doesn't have to resort to tactics like that. They can simply "update" their OEM agreements and pretty much everyone would just have to take it. I SUPPOSE they could Fork Android; but the truth is, not one of them (except maybe Slamdung) has the wherewithal to keep up with Android development internally.

      • I almost wonder whether Google are encouraging people to publicize Android vulnerabilities so they can say 'look, this isn't working, we need to be able to push updates to phones ourselves'. They have to do that if Android has any future.

        Well, there's only one issue with that. All it will take is Google to push out a patch that breaks the custom UI on the phone making it unusable. Carriers/manufacturers don't allow you to disable skins/UI "improvements" so this could potentially be a problem.

  • This is just the beginning. (Score:1)

    by Anonymous Coward

    With so much news and controversy generated by these stories, many many more security researchers and companies are going to start doing deeper dives into Android source code and the various forks individual companies use.

    This at once great and scary. Great because it's better to get these vulnerabilities out in the open so they can be dealt with accordingly. Scary because of the market fragmentation, the vast majority of phones will never see security updates. A minority of Android users have the knowhow

  • Can I use this to root my android devices?

    • Re: (Score:2)

      by johanw ( 1001493 )

      Probably, someone at XDA should be able to turn this into a one-click root app. Until phones come with root access from the manufacturer I prefer an OS with holes above the closed systems Apple and Microsoft are selling.

    • Possibly, although the researchers didn't focus on that, and Google has already distributed a patch for the sub-vulnerability that might have allowed it. The system_server can change SELinux policy and insert kernel modules, and I'm sure someone could write a kernel module to make an arbitrary process root.
  • 'The bug (CVE-2015-3825) .. can be used to turn malicious apps with no privileges into "super" apps'

    Except you forgot to mention that the malware (SerializePOC [youtube.com]) has to be already installed on the device. So to get 'hacked' a) download and install malicious app :)

  • Put an object that is of a class known to the system class loader into an Intent extra. Broadcast the intent it such at it will be received by the system (by possibly targeting an intent filter that's already handled by something in the system process). The system, as soon as it reference any of the Intent extras, will deserialize all of them, including the malicious object (that's how the Bundle object, which backs intent extras works). Eventually, even if that object was never used, it's finalize() method

Slashdot Top Deals

The power to destroy a planet is insignificant when compared to the power of the Force. - Darth Vader

Close