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

← Back to Stories (view on slashdot.org)

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

Posted by timothy on Tuesday August 11, 2015 @12:56AM 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.

76 of 105 comments (clear)

Min score:

Reason:

Sort:

Already patched by LichtSpektren · 2015-08-11 01:04 · Score: 2

Google has already patched the SDKs, but I think any apps made with them have to be updated as well.
1. Re:Already patched by rsmith-mac · 2015-08-11 01:11 · Score: 1
  
  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.
2. Re:Already patched by LichtSpektren · 2015-08-11 01:16 · Score: 1
  
  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.
3. Re:Already patched by AmiMoJo · 2015-08-11 02:22 · Score: 1
  
  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 app. As vulnerabilities go it isn't very severe at all, because it requires so much action/stupidity on the part of the user to work. A severe exploit is one that can bypass the user and malware protection.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
4. Re:Already patched by macs4all · 2015-08-11 02:57 · Score: 1
  
  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!!!
5. Re:Already patched by macs4all · 2015-08-11 03:01 · Score: 1
  
  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.
6. Re:Already patched by swillden · 2015-08-11 03:08 · Score: 4, Informative
  
  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.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
7. Re:Already patched by chmod+a+x+mojo · 2015-08-11 03:38 · Score: 1
  
  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 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.
  
  --
  To err is human; effective mayhem requires the root password!
8. Re:Already patched by flopsquad · 2015-08-11 04:07 · Score: 5, Interesting
  
  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... ?
  
  --
  Nothing posted to /. has ever been legal advice, including this.
9. Re:Already patched by macs4all · 2015-08-11 04:07 · Score: 1
  
  it is oss as far as the os goes, but many of google's apps and their underlying service frameworks are closed source. so what you do is compile the os for your device and obtain an archive of the google apps/services exactly like cyanogenmod, et. al. do.
  So, it is Open Source in the same way that OS X and iOS are. Darwin is Open Source. Many Frameworks are Open Source; but then...
  
  So, in that regard Android and iOS/OS X are equivalent. But only one of them seems to be designed with security in mind. Guess which one...
  
  ios is now getting the same security through obscurity pass that osx has gotten.
  LOLOL! That meme has been disproven time and again; and in case you haven't noticed, iOS is no Windows Phone. It still has quite enough marketshare to be a target.
  
  Face it. Android is broken by design.
10. Re:Already patched by macs4all · 2015-08-11 04:13 · Score: 1
  
  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?!?
11. Re:Already patched by wbo · 2015-08-11 04:24 · Score: 1
  
  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 legitimately.
  
  Apple also sells special code signing certificates to developers that are trusted for side loading on any device. They are often issued to companies that develop apps that are for internal use only to avoid cluttering up the app store with apps that are of no use to the general public.
  
  Their is a set of strict requirements that you have to go through to obtain such a certificate but any app signed with such a certificate can be installed on any IOS device totally independent of the app store.
12. Re:Already patched by pushing-robot · 2015-08-11 04:43 · Score: 1
  
  You don't need a paid account to sideload apps anymore:
  http://9to5mac.com/2015/06/10/...
  
  --
  How can I believe you when you tell me what I don't want to hear?
13. Re:Already patched by Krojack · 2015-08-11 06:06 · Score: 1
  
  it is oss as far as the os goes, but many of google's apps and their underlying service frameworks are closed source. so what you do is compile the os for your device and obtain an archive of the google apps/services exactly like cyanogenmod, et. al. do.
  So, it is Open Source in the same way that OS X and iOS are. Darwin is Open Source. Many Frameworks are Open Source; but then...
  Where can I download the iOS source code? Oh wait you can't. But you can download the Android source code
  The only broken part of Android is when other device manufactures get their hands on it. They are the ones that are updating their devices. I have a Nexus 6 which gets updates right from Google. This is no different the someone having an iPhone and getting updates right from Apple.
14. Re:Already patched by macs4all · 2015-08-11 06:36 · Score: 1
  
  Where can I download the iOS source code? Oh wait you can't. But you can download the Android source code [android.com]
  So, can you really expect to compile that and end up with something that you can load into your phone (and have it work?). No. No more than you can download Darwin and expect it to be a fully-functional iOS build.
  
  But actually, you can download some parts of iOS, just like you can download some parts of Android.
15. Re:Already patched by swillden · 2015-08-11 07:04 · Score: 1
  
  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, you should buy one that is unlockable from the manufacturer. This includes all Nexus devices but several other OEMs also sell unlockable devices. Then you do what you like with it.
  Note that I don't actually recommend running rooted. It pretty severely handicaps the Android security model. I really, really recommend against disabling SELinux enforcing mode. Rooting plus "setenforce 0" throws much of the security model out the window. You're more than welcome to do that if you like, of course, but it's a risk.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
16. Re:Already patched by swillden · 2015-08-11 07:06 · Score: 1
  
  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).
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
17. Re:Already patched by IamTheRealMike · 2015-08-11 07:19 · Score: 1
  
  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 hidden switches to allow it. And those people can go ahead and buy hardware that caters for them. For Joe Sixpack a Samsung that won't let the user accidentally give away the keys to the security kingdom is probably the better bet.
18. Re:Already patched by JesseMcDonald · 2015-08-11 07:41 · Score: 1
  
  So, can you really expect to compile that and end up with something that you can load into your phone (and have it work?). No.
  Yes, actually. The AOSP builds should work out of the box in the sense that you can load them onto an Android-compatible phone (with an unlocked bootloader) and run normal Android applications with the stock Android user interface. Some additional functionality may require the installation of closed-source drivers, most notably accelerated graphics and Wi-Fi. The closed-source drivers needed to run AOSP with full functionality on various Nexus devices are distributed for free by Google.
  By contrast, while there are some open-source components in iOS, they only extend up to the UNIX core (Darwin) and do not include any of the user interface components. If you tried to build the open-source parts of iOS the result would not only be lacking support for various standard hardware (with no drivers available, open source or otherwise), it wouldn't even be an image you could load on your iPhone, and even if you manage to get a loadable image it wouldn't have a user interface. AOSP may lack the proprietary Google applications and open-source versions of some device drivers, but it otherwise comprises a complete operating system.
  
  --
  "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
19. Re:Already patched by geminidomino · 2015-08-11 07:56 · Score: 1
  
  ios is now getting the same security through obscurity pass that osx has gotten.
  LOLOL! That meme has been disproven time and again; and in case you haven't noticed, iOS is no Windows Phone. It still has quite enough marketshare to be a target.
  The only thing "disproven" is any claim you might ever have made about understanding what "security through obscurity" means.
  Protip: it's got fuckall to do with market share.
20. Re:Already patched by macs4all · 2015-08-11 08:15 · Score: 1
  
  The only thing "disproven" is any claim you might ever have made about understanding what "security through obscurity" means.
  
  Protip: it's got fuckall to do with market share.
  Really? I've been around these parts since 2004, and that's what most, if not all, Slashdotters seem to claim again and again as to why OS X has no (or virtually no) Malware.
  
  I understand that, technically, "security through obscurity" actually refers to intentionally (or unintentionally) obsfucated code allegedly being harder to reverse-engineer an exploit for; but you have to admit, the de facto meaning on Slashdot does often (if not always) refer to marketshare (or lack thereof) making a "smaller" (or at least "less desirable") target.
21. Re:Already patched by SirJorgelOfBorgel · 2015-08-11 09:08 · Score: 1
  
  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...
22. Re:Already patched by JesseMcDonald · 2015-08-11 10:01 · Score: 1
  
  So, other than being incomplete, it's complete, right?
  No, it's complete, period. It may not contain every bit of software in the world, like Google's proprietary apps, but AOSP builds are usable on actual hardware in their own right. This is quite unlike the open-source fragments of iOS, which are just that: fragments.
  Sure, both Android and iOS as shipped on most consumer devices contain some open-source parts and some proprietary parts, but let's not make a false equivalency here. Android, even without Google's applications, is a fully usable operating system for smartphones and tablets. Depending on the specific hardware in that smartphone or tablet you might need some closed-source drivers to enable functionality like graphics acceleration or Wi-Fi—which Google provides—but you do have the option of running AOSP on equivalent hardware which does have open-source drivers (e.g. Android on x86). iOS, on the other hand, is a predominately closed-source operating system with a few open-source components. The bits of iOS available as open source aren't even enough to give you a basic iOS-style user interface; none of the graphical parts are included, and even if they were, there are no publicly-available drivers which would allow you to run the open source parts on Apple's own hardware the way that Google supplies the drivers necessary to run AOSP builds with full functionality on the Nexus line of smartphones and tablets.
  
  --
  "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
23. Re:Already patched by farble1670 · 2015-08-11 12:36 · Score: 1
  
  So, it is Open Source in the same way that OS X and iOS are. Darwin is Open Source. Many Frameworks are Open Source; but then...
  no, android the OS is open source. google apps are not open source.
24. Re:Already patched by farble1670 · 2015-08-11 12:41 · Score: 1
  
  So, can you really expect to compile that and end up with something that you can load into your phone (and have it work?).
  yes, people do it all the time. you can start here:
  https://source.android.com/sou...
25. Re:Already patched by farble1670 · 2015-08-11 12:44 · Score: 1
  
  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?
26. Re:Already patched by Namarrgon · 2015-08-11 13:41 · Score: 1
  
  Hence the GP's closing sentence. You've been informed; the rest is up to you.
  
  --
  Why would anyone engrave "Elbereth"?
27. Re:Already patched by flopsquad · 2015-08-11 14:15 · Score: 1
  
  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.
  
  --
  Nothing posted to /. has ever been legal advice, including this.
28. Re:Already patched by flopsquad · 2015-08-11 14:33 · Score: 1
  
  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).
  
  --
  Nothing posted to /. has ever been legal advice, including this.
29. Re:Already patched by flopsquad · 2015-08-11 15:09 · Score: 1
  
  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 expiration date prior to any Active builds.) This phone is going back anyway, since it is less waterproof than advertised. :(
  
  The new Nexus looks promising, and the OnePlus 2 could be cool if they made more than 50 of them. I dunno, even the upcoming iPhone will probably be hackable before the Active...
  
  --
  Nothing posted to /. has ever been legal advice, including this.
30. Re:Already patched by swillden · 2015-08-11 17:36 · Score: 1
  
  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.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
holy crap by Anonymous Coward · 2015-08-11 01:07 · Score: 2, Interesting

this is getting silly. I'm gonna go get an old ass nokia non-smart phone and just be happy.
Android or is it Java? by Lawrence_Bird · 2015-08-11 01:47 · Score: 1

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 changing the Bundle’s default behavior
that automatically instantiates all of its values (under
BaseBundle.unparcel, that is invoked by any ’touch’
of the Bundle) to a lazy approach, i.e. retrieving
only the values of keys it is asked for. Of course by
design the problem will still remain, but will depend
more on specic developer’s code, so less apps will
be vulnerable if another vulnerable class is found,
signicantly narrowing the attack surface.
1. Re:Android or is it Java? by oh_my_080980980 · 2015-08-11 02:03 · Score: 1
  
  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...
  
  So it doesn't sound like Java.
2. Re:Android or is it Java? by allquixotic · 2015-08-11 02:28 · Score: 2
  
  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 grossly inefficient or just plain wrong. It might also, by default, pick up other objects or parts of your program that you *don't* want serialized. You could argue for an improved language design that would build serialization primitives closer into the language syntax or the precompiler or compiler, and have robust checking for various types of problems; but a good static analyzer should probably be able to find these issues even if the compiler doesn't check for them.
  As the article says, it seems like they are doing a class-by-class search over the Android built-in classes (of which OpenSSLX509Certificate is one, but this is notably NOT in the Oracle Java SE platform, nor in OpenJDK) to identify cases where these classes' particular serialization code (or lack thereof, if they're letting the runtime do it automatically via `implements Serializable`; I'm not sure which it is) might have vulnerabilities. Even if they find a vuln in a class which Oracle Java also has, there's no guarantee that Oracle's is also vulnerable, since they don't share a common codebase. Android uses some API definitions that apparently infringed Oracle's copyright (according to a judge, anyway), but they definitely have not lifted any of Oracle's implementation.
3. Re:Android or is it Java? by davidleelambert · 2015-08-11 04:55 · Score: 1
  
  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 on all current Java platforms a native pointer will fit in a long, so some JNI code does that.
  
  --
  note: I have at least one, possibly two other, Slashdot accounts because OpenID creds can't be merged with an older acco
4. Re:Android or is it Java? by IamTheRealMike · 2015-08-11 04:58 · Score: 3, Informative
  
  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.
5. Re:Android or is it Java? by EStrat · 2015-08-11 05:16 · Score: 1
  
  "...so less apps..."
  Stannis, you take this one
6. Re:Android or is it Java? by Lawrence_Bird · 2015-08-11 08:24 · Score: 1
  
  thank you for the more detailed explanation (also a few responders above you).
Re:Haven't missed Google/Android one bit. by Anonymous Coward · 2015-08-11 01:55 · Score: 3, Funny

I dropped the entire Windows platform last year. It's fantastic sitting back and watching the Windows fanboy's house of cards come crashing down.
Sent from my Potato.
Re serialization issue by freddieb · 2015-08-11 02:09 · Score: 2

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.
1. Re:Re serialization issue by 0123456 · 2015-08-11 02:18 · Score: 5, Insightful
  
  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.
2. Re:Re serialization issue by 93+Escort+Wagon · 2015-08-11 02:32 · Score: 1
  
  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.
  
  --
  #DeleteChrome
3. Re:Re serialization issue by Anonymous Coward · 2015-08-11 02:42 · Score: 1
  
  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.
4. Re:Re serialization issue by swb · 2015-08-11 03:04 · Score: 1
  
  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.
5. Re:Re serialization issue by Anonymous Coward · 2015-08-11 03:06 · Score: 1
  
  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?
6. Re:Re serialization issue by macs4all · 2015-08-11 03:07 · Score: 1
  
  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.
7. Re:Re serialization issue by jareth-0205 · 2015-08-11 04:20 · Score: 1
  
  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.
8. Re:Re serialization issue by danomac · 2015-08-11 04:50 · Score: 1
  
  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.
9. Re:Re serialization issue by norminator · 2015-08-11 08:20 · Score: 1
  
  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.
This is just the beginning. by Anonymous Coward · 2015-08-11 02:43 · Score: 1

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 to update or go to a custom ROM. People won't care about how vulnerable any information stored on these devices might be until it's too late.
If this was as easy as upgrading individual packages/kernel packages, it would be a non issue.
Curious by John+Allsup · 2015-08-11 02:55 · Score: 2

Can I use this to root my android devices?

--
John_Chalisque
1. Re:Curious by johanw · 2015-08-11 03:03 · Score: 1
  
  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.
2. Re:Curious by davidleelambert · 2015-08-11 03:51 · Score: 2
  
  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.
  
  --
  note: I have at least one, possibly two other, Slashdot accounts because OpenID creds can't be merged with an older acco
Re:Back to iOS, then? by mrops · 2015-08-11 03:31 · Score: 1, Insightful

We always get a fanboi!
Psssst... this article is about Android.
Re:Back to iOS, then? by IamTheRealMike · 2015-08-11 04:51 · Score: 3, Insightful

iOS and MacOSX have had tons of bugs to do with deserialization of messages passed inter-process, usually XPC type confusion issues.
This is a very neat sort of attack, but it requires quite a few rarely used features to appear in conjunction to pull off, which is why they only found one exploitable class in the entire Android SDK. Their mitigation suggestions are good and can be implemented with some fairly minor API upgrades. I don't think this bug in particular is going to tip the security balance between iOS and Android much.
Re:Back to iOS, then? by trparky · 2015-08-11 05:01 · Score: 1

It may be fixed but is your device going to get that patch? Oh I'm sorry, your phone is a year old... buy a new phone instead!
Wrong folks to ask by ThatsNotPudding · 2015-08-11 05:22 · Score: 3, Interesting

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.
1. Re:Wrong folks to ask by Krojack · 2015-08-11 06:15 · Score: 1
  
  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.
2. Re:Wrong folks to ask by IamTheRealMike · 2015-08-11 07:16 · Score: 2
  
  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 phones were made by hardware companies that happened to have a software division, and often the firmwares were of very low quality. Carriers do massive QA/acceptance testing on phones not because they are masochists who like wasting money, but because the carrier testing process had a habit of revealing a lot of bugs. This was true even of the G1 (first Android phone). T-Mobile filed lots of useful bug reports against Android and HTC.
  So now you have corporate structures and policies all designed on the assumption that phone manufacturers are full of incompetent, Christmas-deadline-driven embedded developers desperately trying and failing to build working GUIs. And frankly there have been cases in the past where software updates pushed to phones do cause them to regress, even for iPhones and Androids (e.g. think about iOS updates that make the phone really slow).
  Yes, it's easy to hate on carriers if you're a tech geek who wants the freshest code on day one and are OK with some rough edges. For everyone else they add a layer of QA that isn't totally useless. The problems start when carriers aren't structurally flexible enough to create fast-track processes for approving security updates, or trusting enough to let OEMs skip approval for security updates. Then they slow down a process where speed is of the essence.
3. Re:Wrong folks to ask by afidel · 2015-08-11 09:34 · Score: 1
  
  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.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
4. Re:Wrong folks to ask by swillden · 2015-08-11 17:55 · Score: 1
  
  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 elsewhere, invalidating testing you thought you'd completed. Automated testing helps, but not everything can be tested that way, and automated testing has its own issues.
  I work on Android, on the core OS, so I have a little familiarity with these processes as they apply to Nexus devices. One of the biggest considerations that goes into decisions about what to change and when, and when to release what, is "soak time": how long do we have to test and experiment on the device or upgrade or patch before we push it out? This time isn't measured in person-hours, it's measured in calendar weeks, because however much staff you have, there's kind of a maximum rate at which you can find, analyze and address (fix, or otherwise, depending) issues.
  For major releases, we really want to have "soak time" of several *months*, during which almost nothing changes. For small security patches that "shouldn't" affect anything else, we still want at least several days, preferably a couple of weeks. And that's if nothing goes wrong.
  Stuff takes time.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
5. Re:Wrong folks to ask by afidel · 2015-08-12 05:16 · Score: 1
  
  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 because your customers WILL leave to a more secure option if you consistently fail to protect them.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
6. Re:Wrong folks to ask by swillden · 2015-08-12 07:13 · Score: 1
  
  90 days is enough time. You said "days or weeks at most". That is not feasible.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
7. Re:Wrong folks to ask by afidel · 2015-08-12 07:32 · Score: 1
  
  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.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
8. Re:Wrong folks to ask by swillden · 2015-08-12 08:01 · Score: 1
  
  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 them by announcing a formal support policy for Nexus devices. It's interesting to note that the new support policies announced by Google and Samsung are the first in the industry -- including Apple, which has no formal update policy for iOS devices (though in practice they do a great job). It's a sign of things to come, I think.
  (Aside: Many think that Google and Samsung created their update policies in response to Stagefright. Not possible. Given the legal and financial implications of such policies, they take a long time to set up.)
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Linux-gate by tepples · 2015-08-11 05:47 · Score: 1

Any vulnerability in Debian, Fedora, or Android is Linux-gate.
Choose the curator by tepples · 2015-08-11 05:50 · Score: 1

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.
1. Re:Choose the curator by macs4all · 2015-08-11 06:30 · Score: 1
  
  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.
2. Re:Choose the curator by tepples · 2015-08-11 07:07 · Score: 1
  
  F-Droid's Inclusion Policy 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 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 for years despite its source code being available?
Re:Back to iOS, then? by Krojack · 2015-08-11 05:52 · Score: 1

I still wouldn't change back to a device that you don't truly own even after paying $500+ for the device.
The bug can be used to own Android devices .. by nickweller · 2015-08-11 07:35 · Score: 1

'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) has to be already installed on the device. So to get 'hacked' a) download and install malicious app :)
Comment removed by account_deleted · 2015-08-11 11:31 · Score: 1

Comment removed based on user account deletion
Comment removed by account_deleted · 2015-08-11 11:36 · Score: 1

Comment removed based on user account deletion
Comment removed by account_deleted · 2015-08-11 11:48 · Score: 1

Comment removed based on user account deletion
Summary by farble1670 · 2015-08-11 12:32 · Score: 1

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 will be called. Depending on the fields that were present in the serialized form, there is potentially an exploit. This could happen if the implementation of that system class's finalize() method could be tricked into doing something funny by the data in the serialized fields in the object.
This is only a theoretical exploit. It depends on finding a system class with a vulnerability that can be exploited by crafting the data in it's fields, and the usage of those fields in it's finalize() methods.