Live data from Hacker News

Android libstagefright still exploitable

blog.exodusintel.com

61–70 of 150 posts

Re: Android libstagefright still exploitable

#61

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)

Per the wikipedia article[0] ASLR (address space layout randomization) was first added in 4.0 and fully enabled across the OS in 4.1. To go with that, 91% of android phones are on >= 4.1, and 95% are on >= 4.0 [1].

[0] https://en.wikipedia.org/wiki/Stagefright_(bug)

[1] https://developer.android.com/about/dashboards/index.html

Re: Android libstagefright still exploitable

#62
post #31

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?

You could actually have runtime checks by default (in a hypothetical language), and have a smart compiler elide them whenever possible.

    int32 a, b = ...;
    a+b; // there is a check
    // implicitly:
    // if (MAX_INT32 - a 
but

    int32 a = ...;
    // after here: typeof(a) = int32
    int32 b = rand_int(0, 1000);
    // after here: typeof(b) = int32[x|where x >=0 and x 
So the compiler would be able to narrow down the type of a variable, and know what operations are safe to perform. This is probably impossible in the general case (halting problem and so on), but I believe it is very doable if you restrict yourselves to a limited number of subranges. This is like a kind of dependent types, but completely internal (you could expose them, if you wanted though).

The compiler can't only use this extra information to remove overflow checks, but you can also have a language that guarantees there is no overflow - add two int32 and the result is an int64, and so on. And if it can infer that the result fits in an int16, then it can put it in there. But most of the time you would just use int, which means: integer variable of enough length to store my data. int8, int16, int32, maybe a BigNum. Kind of like python does it, but with the ability to pick optimized native types if needed.

Re: Android libstagefright still exploitable

#63
post #50
post #31

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?

Performance. That's an extra branch on every arithmetic operation.

There's a performance cost now because processor instruction sets have dropped hardware overflow detection due to disuse. Current processors are largely engineered to just run legacy C code fast. See eg. https://news.ycombinator.com/item?id=7847980

Re: Android libstagefright still exploitable

#64

Earlier quoted context omitted.

It isn't a new bug; what they're reporting is that the patch which was supposed to fix an already-publicly-disclosed bug doesn't fully fix it.

Can you help me understand this? They're complaining about a bug in the patch implementation and the patch implementation did not exist prior to the patch; ergo, if Google didn't patch the code, they wouldn't be able to write the article. Is that not a new bug almost definitionally? Please help me understand if I am incorrect. I understand the underlying issue which was first reported did not get patched properly, bu…

This is a grey area. Not everyone is going to agree.

For example, if some email client can cause arbitrary command execution by adding a malformed email as CC, like nobody@file:///calc.exe or something, vendor patches it, then the workaround to use the exploit again is nobody@file\:\ / \ / \ /calc.exe , I don't consider that a new bug and doesn't deserve the same grace period for disclosure, IMHO. Now, if it turned out that the email client's ability to show embedded images in the message-body and setting the metadata in a PNG to "file:///calc.exe" caused the calc program to run... I think that IS a new bug and does deserve another grace period because its "point of entry", rendering a PNG and processing its metadata, is very different from parsing the email to/from/cc/bcc fields.

Re: Android libstagefright still exploitable

#65

Earlier quoted context omitted.

I shouldn't be required to do to get security releases. Why should you not be required to do that?

Because withholding security updates over accepting horrifically invasive UI and branding changes is unacceptable. Similar to Microsoft still patching Vista nearly ten years later, Google should be obligated to deliver security patches to all versions of Android within a reasonable timeframe.

Microsoft is a very unusual case, in that they have a brand that is built on legacy support and enterprise stability.

Very few other companies in this industry are willing to put up with the pain of maintaining multiple versions, especially without paying enterprise users who care.

Re: Android libstagefright still exploitable

#66

Earlier quoted context omitted.

What? If your intention is to apoligize Google, can you do it in a more clear way?

I'm not a Google apologist and I don't appreciate your tone. I'm attempting to orient myself so that I can think about what is right and wrong with respect to responsible disclosure in a clear and coherent fashion.

As stated elsewhere, the original bug was reported in April and not publicly disclosed until July. The issue here is that the patch did not sufficiently remove the flaw. This gets to the crux of the debate on what is "responsible" disclosure. One would assume that the patch would be studied by legitimately malicious attackers and presumably they would independently realize the flaw still existed and continue abusing it. By stating that the flaw is still present the public at large can make educated decisions about their handling of MMS messages instead of assuming everything is fixed when in fact it is not. The flip side is now that less capable malicious attackers will also be made aware. And so the endless argument continues.

Re: Android libstagefright still exploitable

#67
post #63
post #50

Earlier quoted context omitted.

Performance. That's an extra branch on every arithmetic operation.

There's a performance cost now because processor instruction sets have dropped hardware overflow detection due to disuse. Current processors are largely engineered to just run legacy C code fast. See eg. https://news.ycombinator.com/item?id=7847980

I think it is time for this removal to be reexamined, considering popular scripting languages like Python and Ruby (which check for overflows on all integer operations) face significant performance hits because of lack of hardware support for these instructions.

Re: Android libstagefright still exploitable

#68
post #57
post #41

Earlier quoted context omitted.

I feel for people whose providers won't upgrade them and I think they've got a good complaint, but if you choose to get off the upgrade path I think it's reasonable to assert that you're assuming responsibility for your own choices and security. I expect it can be backported to 4.x via custom ROMs for folks in that spot.

It's not an apples-to-apples comparison, but Android has been around since 2007, and they're up to API level 22 right now. In that same time period, Microsoft has had the following releases of Windows (excluding Mobile/Phone and Server): Vista, which actually came out in 2006 in the OEM edition Windows 7 Windows 8 Windows 8.1 Windows 10 Windows has had a much slower release cadence than Android. It's a much, much big…

(That said, every time I read an article about Android these days I get the urge to buy a Windows Phone.)

I just did that two days ago, the update situation being one of the reasons (the other that I like a reasonable quality dual SIM phone).

For now, it's just an extra phone to play with (Lumia 640, cheap, great build quality/performance for the price). But who knows ;).

Re: Android libstagefright still exploitable

#69

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...

> Even if Google patches this, there's an incredible delay in getting the patch to users.

I don't think delay is the problem - not being able to get or apply the patch yourself is the problem. Ignoring the somewhat ridiculous requirements to compile Android (200GB of HD space and 16GB of RAM [1]) - you couldn't put it on your Android device due to proprietary drivers for wireless and/or video.

Assuming you can get an updated version - I have noticed that after getting root on my Nexus 6 it won't install new versions of Android. I don't know if it's a by-product of getting root/installing a new recovery or if they have an actual check. I have a legitimate reason for root because I use FreeOTP and it does not have an export feature - so I use Titanium backup to backup and restore the app. Getting the OTP QR codes for: dropbox, gmail, Microsoft account, facebook, srchub, github, paypal etc would take a very long time and considerable effort to recover (hint gitlab).

[1] https://source.android.com/source/building.html

Re: Android libstagefright still exploitable

#70
post #40

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 a…

I'm still unclear on the sandboxing assertion. The mediaserver in current versions is, in fact, pretty well isolated. I've had to work around and defeat lots of this protection for debugging purposes in my professional life, so I know it's there. IIRC you can't read system or app data outside the sdcard area, you can't write anywhere persistent. You can open network sockets and make binder requests, which is not triv…

The original bug was demoed with another privilege escalation exploit, it wasn't clear which one was used. See https://www.youtube.com/watch?t=64&v=PxQc5gOHnKs
Post reply on HN