eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Back in late July, Zimperium zLabs Vice President of Platform Research and Exploitation Joshua Drake made headlines with his initial discovery of the Android Stagefright vulnerability. While Google has since patched those initial Stagefright vulnerabilities, there is now a new crop of Stagefright-related issues that must be patched.
Zimperium today announced a pair of the new flaws, dubbed Stagefright 2.0. The latest flaws include one vulnerability in the Android libutils library and another in the libstagefright media library.
The flaws in libutils are part of code that has been in every Android device released since 2008, potentially exposing more than 1 billion users to risk. While Android is at risk, Drake noted that, to date, Zimperium hasn’t seen any evidence to suggest it is being exploited in the wild.
“The two interrelated vulnerabilities are both required for our exploit to work, but they exist in isolation,” Drake told eWEEK. “One is a vulnerability in a core library API. The other is an insecure use of that API that allows triggering the vulnerability within.”
Drake emphasized that to reduce the risk of exploitation, both vulnerabilities must be fixed, primarily to ensure that other potential insecure uses of the core API cannot be exploited. Google has assigned the identifier CVE-2015-6602 to the libutils vulnerability, while a CVE for the second issue is still forthcoming.
With the original Stagefright vulnerability, Google’s Android Security Chief Adrian Ludwig emphasized that the use of address space layout randomization (ASLR) on some Android phones is able to nullify the exploit.
Now, Drake argues that with the new exploit, ASLR isn’t going to make a difference.
“ASLR is in place but has been rendered moot by several circumstances,” Drake said.
One reason ASLR won’t help is that the Android media server restarts automatically, which means attackers can try their attack repeatedly, Drake said, adding that Zimperium’s experience shows that successful exploitation can take place in as little as one attempt.
“Even if multiple attempts are required, the possibility to repeat attempts without interaction beyond the initial delivery vector means 100 percent reliability can be achieved,” Drake said. “In short, ASLR just isn’t a realistic protection mechanism for Stagefright flaws.”
Drake first reported the two issues to the Google Android Security Team on Aug. 15 by way of Android’s bug tracker at https://code.google.com/p/android/issues/entry. Google quickly responded to the issues and got several engineers directly involved, Drake said.
“They acknowledged the severity and accepted my patch, but unfortunately one of their engineers pushed the fix to AOSP [Android Open Source Project] immediately, instead of waiting for updates to be available to the general public,” Drake said.
Although a patch has been available in the Android Open Source code, Zimperium has continued to hold the issue in confidence until now, he said. So, no updates are available for end users at this time.
“Good guys and bad guys alike scour open-source projects to find recently patched security issues,” Drake said. “Patching an open-source software project without providing an update puts users at risk, if even only for a matter of weeks.”
Drake expects the issues he reported will be patched for end users in the next Google Android update. After Drake’s first Stagefright flaws were fixed by Google in August, Google pledged to issue a regular monthly update for Android security and bug fixes.
While Google is poised to patch the new libutils and Stagefright vulnerabilities, Drake still has even more publicly undisclosed vulnerabilities he’s waiting for action on by Google. In fact, there are eight more security issues that Drake has reported to Google.
“The fate of the remaining eight reported issues is a mixed bag, Drake said.”Several, some with critical severity and some with low severity, are being held privately while they progress through the coordinated disclosure process. The remaining issues were rejected as duplicate because they had already been reported by someone else or internally discovered.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.