Android crypto key theft vulnerability affects 86% of devices
arstechnica.comOne of the first comments there with the partial ARM opcode map shows why this vulnerability is "theoretical" - you can overflow the buffer, but the bytes written to the buffer are restricted so much (values will always be between 43 and 126) that it would be nearly impossible to write useful exploit code.
The details are here:
http://securityintelligence.com/android-keystore-stack-buffe...
"nearly impossible to write useful exploit code" sounds like a worthy challenge to some people I know.
The sad thing is how many of these devices, despite being only a year or two old, may only get patched much later or never.
I find it interesting that Google is forcing the ability to update [1] Android watches, cars, and TV boxes by limiting OEM customization. I guess the carrot approach hasn't been working well enough to convince OEMs.
[1] http://arstechnica.com/gadgets/2014/06/android-wear-auto-and...
Especially glad they're forcing the issue with cars. Imagine if a bug or security vulnerability in Maps led to an accident ("Now turn left NO TURN RIGHT TURN RIGHT NOW").
Functionally, since Google Auto probably doesn't touch the car's own computer system, it's probably no worse than a vulnerability in your phone. But the PR from "Google Auto bug causes accident" sounds so much more terrible than "smartphone bug causes accident".
> Imagine if a bug or security vulnerability in Maps led to an accident ("Now turn left NO TURN RIGHT TURN RIGHT NOW").
I'd like to think that people are smart enough not to do exactly what their GPS tells them to do without questioning it but I'd be wrong [1].
[1] http://www.smh.com.au/travel/travel-planning/travel-news/tak...
People are supposed to tell computers what to do, but in practice it's been the other way round quite a long time.
As an example from the extreme end, I recall an incident that happened to my mother's coworker. (This would be more than 15 years ago now.)
One day, her bank card stopped working. Payment terminals wouldn't authorize anything. ATM's wouldn't allow to even get a cash balance. So, over the lunch she went to the local bank branch to find if there was something wrong. Went to the till, presented the card and ID and explained that all of a sudden her card wouldn't work anymore. The clerk checked from the computer, looked up and responded in a calm manner: "You are dead."
Eventually the reason was discovered too. A full namesake had died and the paperwork for terminating the accounts had gone through. The person doing the closing had done an account search based on the full name only and closed everything.
It took a few weeks to get the mess reversed, much of it spent combating the bank to even accept the existence of a clerical error. As far as I know, they never accepted the responsibility of the cock-up.
As amusing as that anecdote may be, the real problem is this: for the bank clerk, the output from the computer screen overrode the reality that was, literally, standing in front of her. Ever since then, our reliance on computers telling us what to do has only increased.
Drivers, blindly taking instructions from their satnav, will easily ignore the reality around them. We've conditioned our users to believe the computer over their own senses.
Android Auto in cars is just a dumb screencast, like iOS CarPlay.
I hope they do it in a standards-based way this time.
I'm about to return a Sony head-unit that only supports Samsung and Xperia phones via a hellish mix of USB tethering, VNC and uPNP.
I know that car audio isn't normally modified now that manufacturers have gone away from the 1 and 2 DIN formats, but if anyone else is reading this, stay away from the MirrorLink/DriveLink technology. AppRadio is the other competitor and the XDA guys have had more luck in unlocking it for all phones to use.
Hopefully Android Auto supersedes the whole mess.
Yes but the software being screencasted is not the regular phone interface that would not adapt to a tablet-like screen very well and contains many apps that are not useful. The phone detects the connection and casts a special software, optimized for automobile usage. So yes the screen is dumb, but also yes there is a special software that needs to be updated, and the article says that this special software won't be part of the standard Android open source layer.
They're attempting the carrot again with the AndoidOne platform they announced at Google I/O. Supported hardware blocks for OEMs but with google keeping the software updated, so there's reason to be hopeful going forward.
On the flip side I have a Nexus4 "GooglePhone" and the latest update basically crippled it (mobile data wise), so maybe it's not all roses o_0
It would have been interesting if CA legislature had focused on forcing companies to provide security patches for some number of years instead of the 'kill switch' issue.
Maybe the EU will take this up as a part of the baseline warranty requirements they push. You don't have to ship a perfect device, but you do have to provide support for security critical patches for a certain time frame. It seems beyond reckless, certainly unethical, borderline negligent, to ship a smartphone and then just leave it exposed as known vulnerabilities pile up.
Once we're talking about phones with a certain level of sophistication, I think 3 years of auto-pushed security updates is not too much to ask! To me, it's a minimum requirement of any device I would buy, but the average consumer has no idea how vulnerable their device actually becomes over time.