Slashdot Mirror
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.
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.
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.
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.
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
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.
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.
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.