Android busted for carrying Fake ID: OS doesn't check who really made that 'Adobe' plugin Google Android allows malware to masquerade as legit, trusted apps thanks to weaknesses in the way the operating system checks digital certificates of authenticity. The flaw, dubbed Fake ID by its discoverers at Bluebox Security, affects all versions of Android from 2.1 (released in 2010) up to Android 4.4. Although Google …
Google Nexus tablet, Google Android all up to date according to Google, running Google Chrome, connected to the Interweb with fn-fast fiber, go to a Google website, and Google Chrome crashes and burns. This happens several times per week.
Hard to see how this can be anyone's fault except Google.
Google Play and Verify Apps have already been updated to detect this issue, and prevent applications that try to abuse this flaw from being installed. This means two things.
First, that there are no applications in Google Play that exploit this issue. If you stick to Google Play, you're safe from this issue, period. No ifs and buts. Second, even if you install applications from outside of Google Play, you are still safe from this issue. Verify Apps is part of Play Services, and runs on every Android device from 2.3 and up. It scans every application at install and continuously during use for suspect behaviour. In this case, an application that tries to exploit this flaw will simply be blocked from installing or running.
It is time that the OS on a mobile device can be patched the same way a desktop device can. I remember the N9 was that way; if there was an update in the repository, that package would be updated. Security vulnerabilities need to be patched and should not be held hostage by the manufacturer or the carrier. I can see controlling major releases, but minor ones need to be made available.
What? You mean that it should lie there sleeping, as as soon as you wander in and touch it, it will immediately decide that NOW is the exactly optimum time to go out and check for and possibly download and install (varies with settings) all the updates? Thereby plugging up the HDD access and making the machine unusable. God help you if you're on dial-up. The PC is only available on its randomized schedule.
You mean like that? OS and App updates on PC are a major FAIL. No matter how you fiddle the settings, there's always a stray App that sets them back with each update.
OS and App updates on mobile devices are a thousand times less painful than desktops. Granted, my primary Android gadget is Nexus, so I'm not left waiting for years. Apple iOS OS and App updates are very close to optimum.
I used to have a Three branded Samsung Galaxy Ace and it was never patched ever in the two years I owned it. Three said it was Samsung not issuing updates. I had higher hopes this year as I now have an sim-free SIII mini, but that's stuck at 4.1.2 and Samsung (via email) said they're not releasing any more updates for my model...
And both the manufacturers and carriers wonder why people get frustrated and root their phones and/or try alternative Firmwares... <sigh>
And both the manufacturers and carriers wonder why people get frustrated and root their phones and/or try alternative Firmwares... <sigh>
Implying that the Manufactures care that you rooting your Phablet, and installing CyanogenMod... Its not like they don't already have your Money, and you probably weren't likely to buy their next Phablet anyway.
Could security be handled in a more inefficient manner? Google really screwed up this aspect of Android. Millions of users are left vulnerable because Google left the distribution of security updates to manufacturers and carriers, both of which have an economic interest in not providing updates, oh and lets not forget Google's own ridiculously short Android support term of 18 months.
If "Verify Apps" has been updated to detect this issue - as the article suggests it has been, then essentially every Android Device that has the Google Play store from Android 4.4.4 right back to Android 2.2 has been silently updated to combat this issue - regardless of what manufacturers may or may not have done.
It is high time the law was changed to make manufacturers/carriers liable for a failure to provide a timely patch.
Just now most of them just don't give a damn because its in their interest that you either buy a new phone or take out another 2 year contract. And if anything goes wrong to you, your bank account, etc, its none of their problem.
That would change noticeably if they were required to pay up for failure to act. Of course phones will still have bugs, and they can't be expected to indemnify for the unknown, but they sure as hell should be punished for not fixing stuff once they have, say, 1 month's notice.
Edited to add: And do the same for the crappy/creepy "IoT" devices as well.
I'm not sure why any such laws should target just phones and embedded (IoT) stuff.
Surely if you're going to make "laws" it should be along the lines of provide security updates for *any* software as long as possible and at the point that the vendor is no longer able to provide updates (doesn't want to or goes bust) they must release their source code and tools to make it possible for someone else to fix the issue.
"security updates for *any* software as long as possible"
While for any software would be nice, the real problem here is a physical device that cant be used securely after a certain time due to embedded software/firmware. It becomes landfill, a waste of the Earth's resources.
With pure software (i.e. stuff running on a computer, including its OS) you can often change it/upgrade it and not throw something away, and we have had automated patching of OS and applications for years already. So its not like a fancy "new technology" is it?
As far as time scale is concerned, it should be defined in terms of the expected usable life (from the buyer's point of view), so something like at least 5 years after end-of-production.
"Or just carried out responsible disclosure, where they tell Google first, then makes it public when Google had a chance to address it"
Could be, but I'd have expected them to be crowing about it as soon as Google pushed the update, especially once it had been pushed to Nexus devices. As it is, at least 3 months after release to ASOP, I'm not convinced.
"Could be, but I'd have expected them to be crowing about it as soon as Google pushed the update, especially once it had been pushed to Nexus devices. As it is, at least 3 months after release to ASOP, I'm not convinced."
From the article.
"We appreciate Bluebox responsibly reporting this vulnerability to us; third party research is one of the ways Android is made stronger for users," a Google spokesman told El Reg in an emailed statement.
And the reason they waited 3 months is probably to give OEMs a chance to push the update too.
As as been pointed out - patching this does not require a manufacturer Android update- just a Google Play Services update which should happen automatically to all phones that use it on Android 2.3 or above, regardless of manufacturer.
This article really should be updated to reflect this (or at least make it much clearer).
Bluebox security sells 'anti virus' software right? Are we taking their word as unbiased reporting?
Why can't Google push out a more subtle version of Android, that can be universally patched as needed. and still allow the OEMs a-la Samsung to skin-up their GUIs as they see fit. This way everyone wins. As far as Security Patches go....
Then again most of my Devices are already on the latest Kitkat anyway...
> that can be universally patched as needed.
>and still allow the OEMs a-la Samsung to skin-up their GUIs as they see fit.
If you take a look at the AOSP source and maybe try to make it work on some device it soon becomes apparent why that isn't easy to do. Sure Samsung etc could just replace the framework graphics to their crappy looking stuff but they don't want to do that. They want to change the UI enough so that it looks like a Samsung and not a something else. So they will tinker around all over the place.
More times than not vendors will also need to add their own patches to core packages to make it work on their device. Mix into that some vendor binary blobs, hardware specific compiler flags that might make binaries incompatible etc and it becomes very hard for Google to be able to "universally" patch anything in the OS.
Now this issue is actually a bit different than something like heartbleed in openssl which will mean replacing that library in the system partition which means an OTA update.. This is a security issue within Google services that run on top of Android and as other people have mentioned it's been fixed.
... another failure of the byzantine, horribly over-engineered, stovepiped X.509 PKI.
This is a major and embarrassing screwup by Google - properly verifying the entire certificate chain is prominently featured in every reputable discussion of X.509 identity verification. Had the developers in question, y'know, Googled the subject, they'd have easily found a list of instructions telling them what they had to do.1
But the larger problem is that X.509 is a terrible standard, and v3 and all the other crap that's been bolted onto it or piled around it has hurt nearly as much as it's helped. PKI is inherently a hard problem, but X.509 went a long way in making it harder.
The PGP/GPG PKI is still much more complex than what Google would need for a simple third-party code-signing mechanism, but it'd be better than X.509. Or, if they must have X.509, only support a reduced feature set and reject anything that doesn't comply with it. Or have devices only accept signatures from Google itself, and have Google Play do the third-party developer signature verification and then countersign the code.
But developers are lazy and fall back on some unfit-for-purpose signature-verification code they found elsewhere in the codebase.
1Or better, read a book like Rescorla's SSL and TLS, which goes into the subject in fairly agonizing detail. Rescorla's book is dry - it makes an excellent cure for insomnia - but then it's a dry subject, and people who want to work in the area need to suck it up and do their damn research.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
