Live data from Hacker News

Android libstagefright still exploitable

blog.exodusintel.com

81–90 of 150 posts

Re: Android libstagefright still exploitable

#81
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…

1. Maybe it's not as easy as you think.

2. The MMS system isn't as anonymous as the Internet and someone didn't want to burn an identity making this worm.

3. A combination of 1 and 2, where the people with technical skill to do this would only use it on specific targets.

Re: Android libstagefright still exploitable

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

How would you know? A well written exploit would immediately hide the notification of itself.

Re: Android libstagefright still exploitable

#83
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…

Because, despite the hype, the bug doesn't give full root access to the phone.

Re: Android libstagefright still exploitable

#84

Earlier quoted context omitted.

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.

How would you know? A well written exploit would immediately hide the notification of itself.

Because my wife's iPhone has not been saturated with MMS messages from bots.

Re: Android libstagefright still exploitable

#85
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…

Didn't a number of texting apps, possibly including hangouts, update to fix it separate of this botched fix?

EDIT: I just checked and sure enough my texting app, QKSMS, updated to remove the Stagefright library

Re: Android libstagefright still exploitable

#86

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.

It's a bit surprising because so much of Android is written in Java. Given hardware decoding of the video itself I wonder why Stagefright needs to be written in C++ at all. Media processing code has been notorious for being exploit ridden for years, so it's not like this problem was unpredictable.

Re: Android libstagefright still exploitable

#87
post #58
post #40

Earlier quoted context omitted.

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 isolation seems mostly defined by this SELinux policy: https://github.com/android/platform_system_core/blob/lollipo... service media /system/bin/mediaserver class main user media group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm ioprio rt 4 You'd need another exploit to elevate from SELinux (and I think send MSSes for a self-propagating worm). Though given Android's abysmal patching, most An…

That's not an SELinux policy? That's just a service statement for Android's init, defining the process' supplementary groups. There is no explicit seclabel I can deduce.

Re: Android libstagefright still exploitable

#88
post #74
post #40

Earlier quoted context omitted.

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.

Yes, audio and camera are there, which means that you also have access to the graphics memory managed by gralloc/hwcomposer too (though surfaceflinger itself is a separate process -- whether mediaserver has access to all such buffers or just ones passed to it from elsewhere is platform-dependent I think), as well as enough of the display driver to spit audio streams out via HDMI, etc...

All that kernel code tends to be complicated and poorly audited, so it would be a plausible hole. But that's not a "sandboxing" problem exactly.

Re: Android libstagefright still exploitable

#89
post #57

Earlier quoted context omitted.

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…

The fact that Google created a huge maintenance burden for themselves shouldn't absolve them of responsibility to provide that maintenance. Microsoft supports Windows versions for ten years, and I agree that's crazy for Android. However, three years I feel is a bare minimum expectation. Devices tend to remain on the market for about a year, and the standard phone contract is two years. So three years from a version r…

I agree that DEVICES should be covered for n years, where n is somewhere between 3 and 5 and we can quibble about the specifics later. I don't think that backporting fixes should be the way we gauge this if newer versions are available instead.

Re: Android libstagefright still exploitable

#90
post #58
post #40

Earlier quoted context omitted.

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 isolation seems mostly defined by this SELinux policy: https://github.com/android/platform_system_core/blob/lollipo... service media /system/bin/mediaserver class main user media group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm ioprio rt 4 You'd need another exploit to elevate from SELinux (and I think send MSSes for a self-propagating worm). Though given Android's abysmal patching, most An…

I could have sworn I read in the OP a few minutes ago, that mediaserver runs as "system" on some devices, which would probably be worse. I'm not finding it now, so maybe it was edited or I'm mis-remembering.

Anyway, vendor customization diverging from AOSP makes it hard to say.

Post reply on HN