Stagefright Patch Incomplete and Zero Day in Android Google Admin App Found

msm1267 writes: A patch distributed by Google for the infamous Stagefright vulnerability found in 950 million Android devices is incomplete and users remain exposed to simple attacks targeting the flaw. Researchers at Exodus Intelligence discovered the issue in one of the patches submitted by Zimperium zLabs researcher Joshua Drake. Google responded today by releasing a new patch to open source and promising to distribute it next month in a scheduled OTA update for Nexus devices and to its partners. Drake's original patch failed to account for an integer discrepancy between 32- and 64-bit, Exodus Intelligence said. By inputting a specific 64-bit value, researchers were able to bypass the patch. Exodus, which submitted a bug fix of its own to Google, said it decided to go public with its findings for several reasons, including the fact that the vulnerability was widely publicized by Zimperium before and during Black Hat, not to mention that Google has had the original bug report since April, yet neither party noticed the discrepancy in the patch. The Android security team at Google is having a busy month. Trailrunner7 writes: Researchers at MWR Labs have released information on an unpatched vulnerability that allows an attacker to bypass the Android sandbox.

Comments

Android is the new Windows XP

[Anonymous Coward]

It seemed for awhile several years ago that every other day there was a new nasty vulnerability in Windows XP. Some of these got exploited by nasty worms such as Blaster. Part of the issue was that Windows was designed without enough concern for security, something that really has changed in the past several years. But users also weren't installing Windows updates like they needed to, leaving them unprotected from exploits. That forced Microsoft to make some big changes in the design of Windows and to its practices in distributing updates. There are still plenty of Windows vulnerabilities, many of which are critical, but updates get distributed and installed much quicker and by a much larger proportion of the users. I'm less bothered by Android vulnerabilities being found and more concerned about how the patches get distributed. Android is a great target for criminals looking to exploit users because it has a large market share and many devices don't get updates regularly. I'd be far less bothered if I could trust that Samsung and Verizon would push out an update promptly, but that doesn't happen. I don't feel particularly vulnerable just because these security holes are being found; however, I don't trust that my Galaxy Note 4 will get an update pushed out to it in a timely manner. I'm not sure how seriously Google takes this, either, if they're going to wait until next month to release a fix. Microsoft did a lot to address the security issues with Windows. A similar thing needs to happen very soon with Android.

Re:Exploit?

[phantomfive]

The second one is easily exploitable, but requires that an app send a malicious URL to the admin app. In other words, for it to work, you need to either install a malicious app, or have another app on your device with its own vulnerability.

The first one can be exploited by sending an SMS to a vulnerable device, according to this report. The fundamental flaw here is running the MPEG decoder as a trusted user. Until that changes, there will likely be a steady stream of vulnerabilities.

Exodus is wrong

[swillden]

Exodus is wrong.

The flawed patch they mention in their post isn't the one being pushed to devices. What makes this funny is that the correct patch is in AOSP, for everyone to see. What Exodus posted is the patch that jduck suggested. And it's in AOSP here. But Google further updated it with this, which fixes the flaw Exodus noticed in jduck's fix.

There are still some known ways to crash libstagefright, but they're assertion crashes. They crash safely, no possibility of exploitation.

Re:Exodus is wrong

[Anonymous Coward]

Prediction: On 64-bit machines GCC and clang will complain about the comparison (SIZE_MAX < chunk_size) being always false. Then some idiot will remove the code to fix the warning, thus silently breaking 32-bit builds. Alternatively, they'll disable the warning, possibly causing future logic bugs to slip through.

The better fix here would be to not use the magic variable SIZE_MAX, as its use relies on unenforced assumptions about its relationship to the type of the critical expression of interest. One way to do that would be

if (~chunk_size < size) { return ERROR_MALFORMED; }

however that relies on knowing that the width of the type of chunk_size is >= that of size. You could add a static_assert to check that. Or you could do something like

#define E_MAX(E) (~((0)? (E) : 0))
if (E_MAX(chunk_size + size) < size) { return ERROR_MALFORMED; }

What E_MAX does is ensure that 0 is promoted to the type of the expression E, which will be the type of the operand with the maximum width. Presuming this type is unsigned, it's all kosher C (and C++) code. This will be true if chunk_size and size are both unsigned and have a rank greater than or equal to int. E is never evaluated, so it has 0 runtime cost. (There are similar tricks you can do check the signedness of E, allowing you to make the macro more generic, at least for all integer types with a width >= int. Calculating the max of a signed type is more complex, but doable as long as the implementation is consistent about it's choice of representation for all integer type. C only permits 3 possible representation--twos-complement, ones-complement, and signed-magnitude, and you can using similar macro tricks to detect and handle the possibilities.)

Even better, though, would be adding proper allocation functions that correctly handle checking for arithmetic overflow, similar to OpenBSD's reallocarray interface (which handles multiplicative overflow).

Thank goodness the code isn't using _signed_ integers as most C++ programmers seem to recommend. Mixing signedness issues with width issues compounds your problems many fold, particularly in contexts where values < 0 are meaningless or hazardous. But as I mentioned in the parenthetical there are well-defined ways in C to handle some common pitfalls when dealing with signed types.

Re:Exploit?

[swillden]

The second one is easily exploitable, but requires that an app send a malicious URL to the admin app. In other words, for it to work, you need to either install a malicious app, or have another app on your device with its own vulnerability.

You're talking about the Certifi-gate vulnerability. Another requirement for it to be exploitable is that your device has to have an exploitable remote admin tool installed by the OEM.

The first one can be exploited by sending an SMS to a vulnerable device, according to this report [exodusintel.com]. The fundamental flaw here is running the MPEG decoder as a trusted user. Until that changes, there will likely be a steady stream of vulnerabilities.

That is the stagefright vulnerability. It's exploitable on ICS and below. The patch being pushed to many OEM devices right now fixes it. Exodus is wrong about that because they're looking at only one of the patches applied. Jduck's original patch had a bug, which Google fixed. All of this is visible in AOSP.

Google... Heal Thyself

[Dutch Gun]

From the article:

The flaw was initially reported over 120 days ago to Google, which exceeds even their own 90-day disclosure deadline.

Do you remember them throwing Microsoft under the bus by releasing information about a flaw before it was patched? Yeah. Oops.

In summary, the Stagefright disclosure process was an interesting one to observe. The (un)surprising outcome being that given all the exposure this vulnerability received combined with essentially infinite resources on the vendor side, effective security mitigations were still not deployed. Google employs a tremendously large security staff, so much so that many members dedicate time to audit other vendor’s software and hold them accountable to provide a code fix within a deadline period. If Google cannot demonstrate the ability to successfully remedy a disclosed vulnerability affecting their own customers then what hope do the rest of us have?

I don't particularly dislike Google. I use Android and several of their services. Sometimes, however, their sense of self-satisfaction can get on my nerves, especially when they demonstrate themselves capable of the same flaws as their competitors but don't seem to own up to it.

Patched in Cyanogenmod in tonight's nightlies

[the_humeister]

See the blog post.