One 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 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.
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".
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.
[+] [-] userbinator|11 years ago|reply
The details are here:
http://securityintelligence.com/android-keystore-stack-buffe...
[+] [-] nutate|11 years ago|reply
[+] [-] MBCook|11 years ago|reply
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...
[+] [-] andrewfong|11 years ago|reply
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".
[+] [-] BuildTheRobots|11 years ago|reply
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
[+] [-] zaroth|11 years ago|reply
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.