3 ms·

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++ l

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.

pacquiao882 11y ago
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.
ajross 11y ago
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?
- semenko 11y ago
  The isolation seems mostly defined by this SELinux policy: https://github.com/android/platform_system_core/blob/lollipop-mr1-release/rootdir/init.rc#L564 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...
  - vezzy-fnord 11y ago
    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.
    - scintill76 11y ago
      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.
    - semenko 11y ago
      Whoops, yep -- definitely wasn't that clear. As pointed out below, the policy is linked to: https://android.googlesource.com/platform/external/sepolicy/+/master/mediaserver.te https://android.googlesource.com/platform/external/sepolicy/...
  - scintill76 11y ago
    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.
    - pacquiao882 11y ago
      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.
- rcheu 11y ago
  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 https://www.youtube.com/watch?t=64&v=PxQc5gOHnKs
- guelo 11y ago
  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.
  - ajross 11y ago
    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.

pacquiao882 11y ago

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.

ajross 11y ago

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?

semenko 11y ago
The isolation seems mostly defined by this SELinux policy: https://github.com/android/platform_system_core/blob/lollipop-mr1-release/rootdir/init.rc#L564 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...
- vezzy-fnord 11y ago
  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.
  - scintill76 11y ago
    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.
  - semenko 11y ago
    Whoops, yep -- definitely wasn't that clear. As pointed out below, the policy is linked to: https://android.googlesource.com/platform/external/sepolicy/+/master/mediaserver.te https://android.googlesource.com/platform/external/sepolicy/...
- scintill76 11y ago
  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.
  - pacquiao882 11y ago
    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.
rcheu 11y ago
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 https://www.youtube.com/watch?t=64&v=PxQc5gOHnKs
guelo 11y ago
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.
- ajross 11y ago
  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.