When the Stagefright vulnerability was made public by Zimperium (months after it had already disclosed it to Google), Google said that although it's a serious vulnerability, most Android 4.0+ devices should be quite safe against it thanks to the ASLR protection.
However, according to one of Google's own security researchers who works for the "Project Zero," attackers could relatively easily bypass ASLR and exploit the Stagefright vulnerabilities. Project Zero is a group of highly skilled security researchers that Google hired to find vulnerabilities that can be used in targeted attacks.
The vulnerabilities found in the Stagefright media library in Android affect almost one billion users -- essentially everyone with an Android 2.3 phone or newer. To make matters worse, the initial series of patches introduced their own vulnerabilities, later found by Exodus Intelligence, another security firm.
The ASLR protection was implemented in Android 4.0 partially, and then fully in Android 4.1, and is meant to protect against some types of memory corruption bugs such as buffer overflows. ASLR randomizes where the exploit lands in the app's memory, therefore making it difficult to take advantage of the existing bug. If the exploit can't find the bug, then it just results in an app crash, rather than a system takeover.
Google's engineers initially said that this should be enough protection against the Stagefright vulnerabilities. However, a Project Zero researcher found that the ASLR feature in Android uses little entropy and can create only 256 locations in memory, which isn't that many if you're trying to make it very difficult for an attacker to find the memory bug.
This was made worse by the fact that Android's Stagefright library reloads after crashing, giving the exploit the opportunity to simply reload itself multiple times until it finds the bug, bruteforcing the Android ASLR. The address space is re-randomized with each attempt, making it more difficult to find the bug, but it can still be relatively few tries. The Google researcher said that an attacker should have about a 4 percent chance of a successful exploit every minute.
One of the easiest ways to exploit the Stagefright library this way is to use a malware-infected web page that people visit and then attempt to inject the malware by reloading it until it's successful. It could also work through in-app adverts using the WebView embedded browser.
Security experts have said before that Android's 32-bit ASLR protection could be too weak, and now we see just how weak it really is. It's also not clear yet whether 64-bit phones are in a better position. ASLR on 64-bit systems is typically much stronger, but Google may have kept it just as weak on 64-bit devices, too, for performance reasons.
Follow us @tomshardware, on Facebook and on Google+.
ohh wait.. we're not talking about Microsoft?
Ohh of course, I would not be the first comment here if it were microsoft... makes sense!
People will always be angry with a company for mistakes when they have built a poor reputation over a long period of time.
Google have built themselves up a buffer so people can give them some leeway with some mistakes.
If they constantly screw up or start dodgy practices that screw everyone over to make a quick buck their free pass will disappear as well.
For all the crap people say about MSFT, they actually have amazing support and actually try to fix bugs. Hell, their enhanced mitigation toolkit methods already prevent stage-fright like attacks and to this day is the only setup (win 7+ with EMT IE11) to have never been cracked in pwn2own.
More than the fact this issue exists is the problem that even if google were to solve the issue (which they won't ), they have no way to force companies to apply the security fix to phones, since the phone OS can't be patched by Google alone.
Yeah there's going to be a lot of devices in the wild that are vulnerable without an official update path.
The problem is in the way the buffer works, allowing it to overflow the memory allocated to it.
They need to fix their buffers, not find workarounds.
Especially when dealing with data from untrusted sources, programmers need to take the time to add in data validation. It's not difficult to do.
Maybe it is time that they take a hint from iOS and start disallowing in-app adds.