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 are still vulnerable.
You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. If you have not done so already, this is urgent. Furthermore, you should assume that auto-downloading of MMS messages will not ever be safe, no matter how many individual security fixes are applied, until this component of Android is significantly re-architected.
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?
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.
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.
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.
This specific exploit can be initiated whenever metadata for an MP4 file is processed. Disabling auto-download of MMS is an important first step workaround. Be cautious with any untrusted media files on your Android device. Simply creating the thumbnail preview image is enough to silently trigger privileged code execution.
You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. If you have not done so already, this is urgent. Furthermore, you should assume that auto-downloading of MMS messages will not ever be safe, no matter how many individual security fixes are applied, until this component of Android is significantly re-architected.