E-Z-2-Use attack code exploits critical bug in majority of Android phones | Hacker News Reader

E-Z-2-Use attack code exploits critical bug in majority of Android phones

arstechnica.com

44 pointsRougeFemme9 comments

I guess Google doesn't give a fuck about security either <end sarcasm>

I really hope that this kind of publicity will finally make Android phone manufacturers to get off their butts and provide better firmware updating for their devices.

Also, the article doesn't say, but does anyone know how Google provides patches for security vulnerabilities? Can the patch be applied against all versions of the firmware that contained the bug, or does the manufacturer actually have to upgrade the whole firmware? If it's the second, Google shares responsibility for the poor security situation.

As the Android ecosystem is somewhat decentralized, it's mostly up to the manufacturer to release firmware updates. I say "mostly" because there is an in-band "carrier certification" process that applies to most devices in the United States, at least, and the carriers have been known to deny updates in the past.

Updates can be distributed however the manufacturers wish. For Nexus devices, Google distributes binary patches between point releases, and makes full system images available for restoration. Some manufacturers, notably HTC, have distributed some firmware updates as a full 1GB+ system image, and minor updates as patches.

Very rarely has Google pushed a point release in direct response to a security bug. The most recent that comes to mind was a patch to fix the master key vulnerability; it may have been 4.2.1 or 4.4.1, I don't remember.

Typically, manufacturers don't distribute security updates on their own. The release process usually follows a point release upstream. They build a device tree, merge whatever system customization, UI layers, and bundled applications they maintain, perform extensive testing to make sure they haven't broken something that was changed upstream, go through rounds of carrier certification, and finally the update is pushed as an optional OTA to devices.

For these reasons, it is difficult and expensive to distribute security patches to older, non-supported devices. I'm not going to comment on Google's share of any blame for this process.

This is just a collection of excuses the vendors have been parroting but they don't really stand up to scrutiny.

1) The carriers problem is unique to the US, the same (or nearly same) situation persists for unlocked devices. In the US you can just look at the situation with (wifi-only) tablets. No updates there either.

2) Google point releases could be more frequent and Nexus device support should go on for longer, but that's no excuse for the non-Google norm of completely abandoning your device shortly after launch.

3) Correct, they don't distribute security updates. It is wrong.

You can say eg. maintaining a stable WebKit version with backported security fixes is expensive and difficult, but it's not. And Google is probably doing it for them. And if not, they can just cooperate on it, this being open source. And when at some point their Android/WebKit version falls too much behind they just have to decide between updating to latest WebKit or replacing it with "sorry out of order" popup.

The code is here: https://github.com/rapid7/metasploit-framework/blob/master/m...

I can't get it to do anything on my s3 or my nexus tablet.

My very non-destructive implementation is here: http://9ol.es/ex.html - I'm editing it live btw.

only works on android < 4.2 with the stock browser and shady apps that have ads. A lot of devices out there are people with 3yr contracts still running vuln unpatched versions though

Ah ok. So then it looks like that over half of the android phones listed here for sale right now: http://www.frys.com/ads/page16#AdNavi would be susceptible to it. That's pretty bad.

I can't find any info about how the stock browser can be abused. All code I've seen so far abuses ad libraries that allow ads to even make calls without user interaction... If you install ad based apps, you should expect that anyway.

From my testing, in stock android 3.1-4.1.2, the native browser has some java objects injected into it and is vulnerable, so any page on the internet could execute arbitrary code. You can verify yourself by downloading the SDK and trying the metasploit module on different targets. Of course with vendor patches it's anyone's guess as to what code is on a device, so it is very possible that some vendors have patched this in their older distributions. If you want to check your device, jduck put up a test script here:

http://www.droidsec.org/tests/addjsif/

Thanks.

2.3.3 cm7.1 is the only one safe here.

Reply on news.ycombinator.com