Old Apache Code At Root of Android FakeID Mess 127
chicksdaddy writes: A four-year-old vulnerability in an open source component that is a critical part of Android leaves hundreds of millions of mobile devices susceptible to silent malware infections. The vulnerability affects devices running Android versions 2.1 to 4.4 ("KitKat"), according to a statement released by Bluebox. The vulnerability was found in a package installer in affected versions of Android. The installer doesn't attempt to determine the authenticity of certificate chains that are used to vouch for new digital identity certificates. In short, Bluebox writes, "an identity can claim to be issued by another identity, and the Android cryptographic code will not verify the claim."
The security implications of this are vast. Malicious actors could create a malicious mobile application with a digital identity certificate that claims to be issued by Adobe Systems. Once installed, vulnerable versions of Android will treat the application as if it was actually signed by Adobe and give it access to local resources, like the special webview plugin privilege, that can be used to sidestep security controls and virtual 'sandbox' environments that keep malicious programs from accessing sensitive data and other applications running on the Android device. The flaw appears to have been introduced to Android through an open source component, Apache Harmony. Google turned to Harmony as an alternative means of supporting Java in the absence of a deal with Oracle to license Java directly.
Work on Harmony was discontinued in November, 2011. However, Google has continued using native Android libraries that are based on Harmony code. The vulnerability concerning certificate validation in the package installer module persisted even as the two codebases diverged.
The security implications of this are vast. Malicious actors could create a malicious mobile application with a digital identity certificate that claims to be issued by Adobe Systems. Once installed, vulnerable versions of Android will treat the application as if it was actually signed by Adobe and give it access to local resources, like the special webview plugin privilege, that can be used to sidestep security controls and virtual 'sandbox' environments that keep malicious programs from accessing sensitive data and other applications running on the Android device. The flaw appears to have been introduced to Android through an open source component, Apache Harmony. Google turned to Harmony as an alternative means of supporting Java in the absence of a deal with Oracle to license Java directly.
Work on Harmony was discontinued in November, 2011. However, Google has continued using native Android libraries that are based on Harmony code. The vulnerability concerning certificate validation in the package installer module persisted even as the two codebases diverged.
Re:Thankfully those will be patched right in a jif (Score:5, Informative)
The patch already exists [phandroid.com], now it's up to our cell carriers to distribute it.
Re:Thankfully those will be patched right in a jif (Score:5, Informative)
READ THE MOTHERFUCKING SUMMARY! (Score:2, Informative)
JESUS FUCKING CHRIST, I know this is Slashdot, but were you totally unable to read even the second sentence of the summary?
Play Services (Score:4, Informative)
If you have any of Google's apps installed, you'll also have Play Services installed - and this has already been updated to detect attempts to use the specific vulnerable certificates involved. If you only get your apps from the Play Store, you're fine, as they've already all been scanned (and no exploit attempts detected). Even if you sideload, so long as you left the Verify Apps checkbox on (default setting), then Play Services will scan any sideloaded apps too (no exploit attempts have been detected that way either).
While the vulnerability is a serious one, it's not something that will concern the vast majority of Google's Android users. It's probably a lot more significant for companies like Amazon, who will have to develop their own response, and (inevitably) for all those millions of Chinese users of generic non-Google Android derivatives.
Re:I call BS (Score:2, Informative)
There is no tribe called simply the "Apache". Though, the word Apache is used in the name of several of the tribes that make up the ethnic group. There are numerous tribes in the Apache ethnic group. One of largest of these tribes is the Navajo which doesn't use the word Apache in the tribal name.
Re:Thankfully those will be patched right in a jif (Score:5, Informative)
I only said 10%,
Then where does the 10% claim come from?
Oh right - it was made up by AV vendors trying to scare peopple into buying their products.
Unless you’ve had your head under a rock you’ll have noticed the latter is fast becoming the weapon of choice for Google’s rivals in attempting to curtail the former. On paper it should. Android malware rose from 238 threats in 2012 to 804 new threats in 2013. What was the combined total of new threats for Apple iOS, BlackBerry OS and Microsoft Windows Phone in that time? Zero. The remaining 3% came from Nokia’s axed Symbian platform.
All of which poses a very valid question: how do you stay safe on Android? Perhaps surprisingly the answer is: easily. Why? Because here’s the part Google’s rivals don’t want you to know: the figures are misleading.
Let’s be clear. From a statistical viewpoint researcher and security specialist F-Secure got them right. Android does account for 97% of all mobile malware, but it comes from small, unregulated third party app stores predominantly in the Middle East and Asia. By contrast the percentage of apps carrying malware on Google’s official Play Store was found to be just 0.1%
http://www.forbes.com/sites/go... [forbes.com]
So that one's busted. Anything else you'd like to sell?
Re:Appalling (Score:5, Informative)
I don't know the fine details of this bug, but am I the only one appalled at how obvious this bug sounds? It doesn't even properly check the certificate? I mean buffer overflows and such are one thing, but not properly testing your certificate code seems unforgivable.
No, it's not that it doesn't check certificates generally, it's that if there's an additional, extra certificate of a particular form in the list that forms an app's certificate chain (but isn't actually in the chain) then that extra certificate gets included in the list of signatures associated with an app... making other apps that query the signature list believe that the app is signed by a certificate it's not. This doesn't, for example, fool the Play store into believing an app is from developer A when it's really from developer B. But it can fool other apps. There are some apps that load others as plugins, and make decisions about which plugins to load based on whether they're signed by a particular key. This flaw allows malicious apps to subvert that, convincing the plugin-loading apps to execute them, thereby giving the malicious app the same permissions as the plugin-loading app.
It's a serious security flaw, no doubt. But it's a little more subtle and less obvious than the summary makes it appear. Also, it appears that no app in the Play store, nor any of the other apps that Google has scanned, attempt to exploit the flaw. It's very easy to identify them by scanning the certificates in the package.
I've implemented tests for certificate chain validation code several times (not in Android), and it never once occurred to me to test for this particular odd construction, nor, I think, would anyone else think to test for it without some specific reason. This sort of bug requires inspection of the code.
(Disclaimer: I'm a member of the Android security team, but I'm not speaking in an official capacity, just summarizing what I've read of the vulnerability -- which isn't a great deal. Others on my team are well-informed, but I haven't followed this issue closely.)
Re:Thankfully those will be patched right in a jif (Score:4, Informative)
I'm pretty certain Google has systems in place (as well as an after the fact kill function) to eradicate malicious apps that find their way onto the app store. Doubtless there are some there but they're background noise.
Re:Thankfully those will be patched right in a jif (Score:5, Informative)
At the end of the day, android gives users the freedom to choose where they get apps from. But freedom implies the freedom to do stupid things. It won't stop a user installing warez if they want, but if they get owned it's their own damned fault. Not much different from what happens on a PC or Mac really.
That said I don't think Android does enough to protect users from malicious or rogue apps, e.g. allowing the device to deny a permission to the app even if it claims to need it. Cyanogenmod demonstrates it can be added, but Google haven't seen fit to provide that functionality in the stock android code.