Last week Google, Samsung, LG and other major smartphone manufacturers promised to patch the Stagefright vulnerabilities promptly, and some of them have already started to send the fixes over the air. However, according to researchers from Exodus Intelligence, the patch itself isn't a great one and still allows attackers to exploit the Stagefright media library.
Researchers from Zimperium initially found the vulnerabilities in Android's Stagefright video library, which affected an estimated 950 million users, and reported the problem to Google four months ago.
Stagefright Saga Continues
One of the patches for the "Google Stagefright 'tx3g' MP4 Atom Integer Overflow" vulnerability was only four lines of code. Researcher Jordan Gruskovnjak from Exodus Intelligence noticed something might be wrong with that patch, but couldn't verify it until devices began receiving it from Google.
After the patch was sent to the Nexus 5, the researcher managed to create an MP4 file that would bypass the patch, and he received a crash message, which points to some level of success.
Android 4.0 and later versions received support for a security feature called address space layout randomization (ASLR), which makes it much harder for attackers to insert malware into Android devices. However, its exploitation is not impossible for skilled hackers, and Exodus Intelligence believes the newly uncovered vulnerability in Google's patch will need to be fixed as well.
The company has already collaborated with Zimperium, the original discoverers of the Stagefright vulnerabilities, to cover the new bug in its Stagefright Detector app, which it recently launched.
“We've been in contact with Zimperium and are working with them to provide coverage for detection of this flaw through their Stagefright Detector app. They have been very responsive (more so than the affected vendor) and we plan to alert them of similar flaws we've recently discovered," said the company in a blog post.
Android Security, Forever Doomed?
Ultimately, what this new vulnerability shows is that there will always be dangerous security bugs that could impact hundreds of millions of Android users (if not more as Android expands its market), and Google needs a serious rethink for how it can provide those updates. Otherwise, all of the sandboxes Google throws at Android's design might be irrelevant.
Apple, Microsoft and even the fragmented "Linux" ecosystem all have a much better security update model than Android has right now. In the Android ecosystem, the model seems to be companies fixing stuff whenever they feel like it, and if they feel like it. That's a model that certainly can't scale to billions of users -- not without leaving a majority of them always vulnerable to some bug or another.
The best update system Google has come up with recently -- and only because of a Stagefright-level vulnerability -- is to get a few more OEMs to agree to a monthly security update program. However, this solution is not enough to solve the bigger problem with Android security updates.
First off, none of those companies mentioned if all of their devices will receive updates in such a manner, and they didn't say for how long in their lifecycles this will happen. To make matters worse, in the U.S, they'll only send the updates through the carriers.
Second, only two OEMs, other than Google, agreed to set up this monthly security updates system. Therefore, it doesn't come close to being a total solution for the whole Android ecosystem.
Eventually, Google, as well as all of the OEMs, will have to agree to set up a system where Google controls all of the updates, no matter how much they hate the idea right now. The question is how many more Stagefright-level vulnerabilities will Android users have to endure until that finally happens?
Follow us @tomshardware, on Facebook and on Google+.
Really, I think what we really need is a law against planned obsolescence.
Hopefully organization like Linaro will be able to help in catching to the Linux kernel mainline but that doesn't help with distribution.
I'm not sufficiently well versed to understand exactly how Android is organized. The model that should work for it, tho, is something along the lines of Linux...that there is a core, controlled by a relatively small group, and which can be updated and patched by that group, and NOT by the manufacturers/service providers.
If they can't get to something like this, they'll just drive everyone to Apple. It's not that Apple is virus-free...but they can respond to exposed vulnerabilities much better. Businesses will do this fastest. And I'm by NO means an Apple fanboi...I do have 2 iPod Touches, but those also shw me that I don't want to go any deeper with them. And, of course, Apple ONLY wants to build expensive, perceived-as-ultra-premium devices, and there is NO reason to think that will ever change...it's been their motif from day one. And lack of competition would be very bad.
...I don't think we have any chance of turning that around, but we can dream.
Get a clue. This isn't planned obsolescence. It's the fundamental consequence of rapidly developing and evolving technology, in a wildly competitive market environment.
And right or wrong...EVERY handset maker of midlevel and above units, MUST revamp their lineup at least once every 2 years, or they're going to effectively disappear. With better specs than their last gen. Would Android 2 be capable of driving everything on an S6 Edge adequately? I doubt it.
That said, the vendors should be required to support their devices, including releasing firmware and OS updates for them, for at least 10 years.
android is the base for everything
3rd parties send their drivers to google to make sure crap works
now android of any flavor can be installed and drivers are sure to work on any os version from now to X (major os revision that requires brand new driver certs)
alidan: that makes Google the bottleneck, but I think you're not far off. It should be possible to divorce the GUIs and app-level functionality, which is where the various skins should live, from the hardware-level stuff that might be subject to this kind of certification, and to all the control functionality that should be Google's purview. The issue probably is keeping Android totally open. It's also likely true that getting this kind of code separation is easier said than done.