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

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.

Comments

Already patched

[LichtSpektren]

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

Re:Already patched

[swillden]

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

[flopsquad]

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

holy crap

[Anonymous Coward]

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

Re:Haven't missed Google/Android one bit.

[Anonymous Coward]

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

[freddieb]

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

[0123456]

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.

Re:Android or is it Java?

[allquixotic]

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.

Curious

[John Allsup]

Can I use this to root my android devices?

Re:Curious

[davidleelambert]

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.

Re:Back to iOS, then?

[IamTheRealMike]

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:Android or is it Java?

[IamTheRealMike]

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.

Wrong folks to ask

[ThatsNotPudding]

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:Wrong folks to ask

[IamTheRealMike]

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.