Android libstagefright still exploitable

Re:Android libstagefright still exploitable by ajross on Thursday August 13, 2015 @02:07PM (#10056102)

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 trivial but again rather different from a remote root.

That this is an exploitable bug in libstagefright seems to be uncontested. But AFAICT there are no assertions of an actual sandbox breakout or a practical payload that does something more than e.g. send spam. Are there? Link?

[ Parent | on HN ]

Re:Android libstagefright still exploitable by semenko on Thursday August 13, 2015 @02:25PM (#10056208)

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 Android kernels are also terribly outdated...

[ Parent | on HN ]

Re:Android libstagefright still exploitable by vezzy-fnord on Thursday August 13, 2015 @02:53PM (#10056388)

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.

[ Parent | on HN ]

Re:Android libstagefright still exploitable by semenko on Thursday August 13, 2015 @04:34PM (#10057039)

Whoops, yep -- definitely wasn't that clear. As pointed out below, the policy is linked to: https://android.googlesource.com/platform/external/sepolicy/...

[ Parent | on HN ]

Re:Android libstagefright still exploitable by scintill76 on Thursday August 13, 2015 @02:56PM (#10056406)

The policy is linked. The service definition was probably quoted to show other aspects of its isolation and privileges, but the comment is not written very clearly.

[ Parent | on HN ]

Re:Android libstagefright still exploitable by scintill76 on Thursday August 13, 2015 @02:53PM (#10056391)

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.

[ Parent | on HN ]

Re:Android libstagefright still exploitable by pacquiao882 on Thursday August 13, 2015 @03:27PM (#10056617)

You are correct. It runs with system and graphics privileges on many devices. It is a native service started at system init and is automatically restarted if it crashes.

[ Parent | on HN ]

Re:Android libstagefright still exploitable by rcheu on Thursday August 13, 2015 @02:43PM (#10056317)

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

[ Parent | on HN ]

Re:Android libstagefright still exploitable by guelo on Thursday August 13, 2015 @02:46PM (#10056331)

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.

[ Parent | on HN ]

Re:Android libstagefright still exploitable by ajross on Thursday August 13, 2015 @02:53PM (#10056389)

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.

[ Parent | on HN ]