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:Android is the new Windows XP

[Anonymous Coward]

Google sucks balls. I can't believe people still put up with this shit.

I recently purchased a Microsoft Lumia 735 (Windows Phone) for $190 when I also bought a $700 (or whatever it was) HTC M9 to replace my old Android phone.

It's fucking comical. The Lumia 735 is way faster than the HTC phone, which is like 3 times as powerful.

My work uses google apps, so I'm pretty much stuck. I also am addicted to one night stands on Tinder. But man - Windows Phone is sweet. I can't believe it doesn't get more love. Incredibly fast, it has almost everything you need other than hookup apps. Yelp, opentable, spotify, microsoft maps or whatever it is works fine.

And, to top it off... there are no security vulnerabilities and Microsoft pushes regular updates.

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.

Patched in Cyanogenmod in tonight's nightlies

[the_humeister]

See the blog post.