Hacker News Reader

Comment by ajross | Hacker News Reader

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?

View on HN

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

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.

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.

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

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.

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.

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

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.

Reply on news.ycombinator.com