Any competent malware developer must have already figured out how to exploit this the first time around. Now that every single one of those malware developers has learned it is still exploitable, the payload they've spent the past month perfecting can now be deployed in the wild.

So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten minutes of being released in the wild?

1. Text payload to victim

2. Payload executes on victim's phone and texts itself to all of the victim's contacts

3. Repeat

Assuming the average Android phone owner has 20 contacts who also have Android phones, and assuming also that texting the payload to those 20 people would take two minutes to complete, the infection would spread exponentially and only take ten minutes for the initial text to result in the infection of 10 billion devices worldwide.

Why am I not currently being bombarded with MMS video texts from infected devices? It frankly seems a bit miraculous. Did Google set up an emergency arrangement with all of the carriers to block suspicious video texts so this wouldn't happen?

Summary: A little over two weeks ago, it was publicly disclosed that MMS messages can cause Android phones to decode video with libstagefright, which is a C++ library with vulnerabilities and insufficient sandboxing, leading to remote code execution without user interaction. Today, Exodus Intelligence is reporting that the patch to fix one of these vulnerabilities does not, in fact, fix it. Thus, all Android phones are still vulnerable.

You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. If you have not done so already, this is urgent. Furthermore, you should assume that auto-downloading of MMS messages will not ever be safe, no matter how many individual security fixes are applied, until this component of Android is significantly re-architected.

Is this timeline correct?

April 2015 - Original stagefright exposed

July 31st - Author noticed patch was not sufficient but could not test (did not notify google)

August 6th - Patch released

August 7th - Author notified google that patch was not adequate

August 13th - Author went public?!?!

They are counting the original date of exploitation as the start date for notification. I would think a more responsible and friendly date would be August 7th. Just me.

Even if Google patches this, there's an incredible delay in getting the patch to users. Android in fundamentally flawed in this respect.

http://www.extremetech.com/mobile/197346-google-throws-nearl...

Did I read that right? They reported the bug to Google on August 7th and disclosed it publicly on August 13th?

Is this still responsible disclosure if they give Google basically 6 days to respond and use the original notification date as justification? I'm not learned enough in the practice of responsible disclosure to know if this is common, but I've not seen that before.

Doesn't seem very responsible behavior by the reporter. Google accepted the suggested patches, fixed the original cases. Now some other cases are discovered for these larger numbers, OK, that seems like a new thing to fix next. Not sure why I have to read paragraphs of hate when the company put the suggested patches in already. Seems like just an excuse so they can ride the page view wave.

And I was wondering at the beginning of the article why they were doing

    if (SIZE_MAX - chunk_size <= size)

    if (size + chunk_size >= SIZE_MAX)

What would be more sensible than integer overflow would be to automatically promote integers to a larger type in the context of a comparison, so that they don't overflow. I wonder if you could add that to the language in a backwards-compatible way? Maybe add a new builtin (compiler-specific, but shared by popular implementations?) like

    if __no_overflow(x + y > z)

And while we're at it, add a __checked(a+b) construct, that sets a flag if overflow occurs (or maybe raises an assertion - or maybe we should have both options).

Just to give everyone a bit of calm, nobody's demonstrated a successful exploit with ASLR bypass.

Meaning that while the vulnerable is technically exploitable, the chance of system compromise is very low on modern android phones (I think post 4.0)

>Deadline exceeded – automatically derestricting >The flaw was initially reported over 120 days ago to Google, which exceeds even their own 90-day disclosure deadline.

It always seemed likely that Google's hubris[1] would come back to haunt them. I guess this is that day.

It would be funny if it wasn't remote code execution affecting 950 million phones, with no official patch in sight.

[1] https://news.ycombinator.com/item?id=8896221

Why are arithmetic overflows and underflows not exceptions/crashes by default, like divison by 0?

Aren't the cases where you actually want an over/underflow the exception? Why not resort to special instructions/macros/operators for these operations?

This is a common problem in C. Integer types are inherently type unsafe and are silently promoted with many different rules which are hard to remember and understand. As is seen in this case, even the ( borderline paranoid ) flag -Wconversion would not catch the bug.

I think this problem in C would be solved with a single flag: -Wwarn-if-using-integers-of-different-types-in-an-operation , forcing you to cast the integer if the types don't match in a arithmetic operation, or an assignment.

The bigger issue of libstagefright is that it there's a ton of code involved with media playback at the native level that has access to many system resources. This specific exploit was just looking at a small part of the MP4 handling -- one of the many parts within the library. It is very likely more severe exploits like this one will surface as a result of this huge library.

Can carriers (and by extension, the Hangouts backend itself) check messages and block "evil" ones? Wouldn't that be an easier way of fixing these things quickly?

At the very least, Google should block any Hangouts message that triggers the bug even on non-updated devices.

I think the proper check is:

// size_t size; // uint64_t chunk_size;

if (chunk_size >= SIZE_MAX - size) { return ERROR_MALFORMED; }

Due to size being a size_t and SIZE_MAX being well a maximum size_t, SIZE_MAX-size is properly calculated. The comparison with chunk_size is also properly done (due to the C promotion rules - as strange as they are, they do work "as expected" when your values are nonnegative, which they are here).

Also, I am slightly puzzled why one would use SIZE_MAX as a limit rather than some "small" number, like a few megabytes or whatever is a reasonable bound for this buffer. In this case the fix may be a bit more complex than this: if (chunk_size >= SIZE_MAX - size || size + chunk_size > the_limit) .

There was an Android update pushed to my phone recently. I wanted to know if it was an urgent security fix so I checked the diffs. It's hard to tell but it doesn't seem to be. It's a bunch of fixes to do with video out, SIP etc.

I thought maybe the patch fixed this security flaw. It wasn't clear what it was for from the phone. I had to do a fair bit of digging. Are there any change-logs or release notes for these system updates?

IMO, the Android echosystem is a clusterfuck and Google needs to get a hold of it. I would buy a Windows phone before I would buy an Android device.

http://www.cyanogenmod.org/blog/more-stagefright

Looks like Cyanogenmod has patched this toot-sweet.

So, a security engineer, working at Google, cannot catch that a 4 lines patch is ineffective?

Things like this is why I trust an iPhone enough to handle two-factor auth for banking (in Sweden: "Mobil BankId"), but not an Android device.

I hope Google will raise the security level now that they have reached global dominance, in no small part through lax security (as a consequence to their liberal licensing models).