Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android libstagefright still exploitable

blog.exodusintel.com

Post reply on HN
Print view View original

71–80 of 150 posts

Re: Android libstagefright still exploitable

#71

Post by ocdtrekkie »

azernik wrote: post #65
ocdtrekkie wrote: post #26

Earlier quoted context omitted.

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.

But Google has been heavily pushing their new "Android for Work" concept. Microsoft's support lifecycle is expected by enterprises today. Why on earth should people trust Google with their business data if they won't provide enterprise-level support?

Re: Android libstagefright still exploitable

#72

Post by stevenh »

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?

Re: Android libstagefright still exploitable

#73

Post by SamReidHughes »

nadams wrote: post #69
archmikhail wrote: post #3

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…

> I don't think delay is the problem - not being able to get or apply the patch yourself is the problem.

Almost all users would be incapable of applying patches themselves.

Re: Android libstagefright still exploitable

#74

Post by guelo »

ajross wrote: post #40
jimrandomh wrote: post #7

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…

I believe mediaserver also has microphone and camera access which seems scary, though I don't know what harm a crook could do with it. Spy agencies might be more interested.

In general though I totally agree, the media hype has been irresponsibly overblown.

Re: Android libstagefright still exploitable

#75

Post by cautious_int »

VMG wrote: 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?

Because unsigned overflow will not happen in C, and will instead wrap the value. The variables in question were unsigned.

This is defined and perfectly normal.

However signed integers will cause undefined behavior on overflow and there is a common flag in most compilers to trap on overflow.

Re: Android libstagefright still exploitable

#76

Post by danielweber »

hoopism wrote: post #9

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

I sympathize, but there weren't enough details for Joe Random to build an exploit. This was an attempt to apply pressure, and it did it in the right way, by telling people how they can defend themselves.

Unlike Shellshock which was all over the freaking place, neither I nor my colleagues have gotten any suspicious MMS messages.

Re: Android libstagefright still exploitable

#77

Post by tomp »

matthewmacleod wrote: post #22
x0x0 wrote: post #16

Earlier quoted context omitted.

Eh, fuck google. They still haven't patched the original stagefright for android 4.4.4 on my nexus 5, and I don't want to upgrade to android 5, which I shouldn't be required to do to get security releases.

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

The problem with general updates is that they tend to screw up your workflow, settings, etc. in different ways (they call that "features"). Personally, I'm also more and more reluctant about installing updates for most apps and systems.

Ideally, security updates would be distinct from general system or application updates. Don't Apple and Microsoft do that for their OSs?

Re: Android libstagefright still exploitable

#78

Post by zurn »

johncolanduoni wrote: post #67
zurn wrote: post #63

Earlier quoted context omitted.

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.

The naive check-and-branch approach on current x86 only costs a couple of percent in integer-heavy and well tuned C code (see http://danluu.com/integer-overflow/). Integer operations in Python and Ruby are so glacially slow compared to C that the overflow checking overhead doesn't register at all due to all the other overhead there.

Re: Android libstagefright still exploitable

#79

Post by mike_hearn »

stevenh wrote: post #72

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

Apparently the exploit doesn't work on devices that have good ASLR (based on a /. comment by someone who works on the Android security team).

Re: Android libstagefright still exploitable

#80

Post by barrkel »

ploxiln wrote: post #50
VMG wrote: 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.

That's not how you'd implement it if you had a choice though. You'd rely on a certain page of memory not being mapped on the target platform (the page that starts at address 0 is often a fine choice) and you'd issue a conditional move that touches that address. You'd rely on the CPU exception interrupt mechanism to branch.

I know modern ARM instruction sets don't have conditional instructions like that, but they may have something similar for extremely infrequently triggered control flow. The same kind of trick can be handy in a variety of programming language and GC implementation techniques.

Post reply on HN