Skip to main content

Android N Media Stack Sandboxing Could Protect Against Future 'Stagefright' Vulnerabilities

Google unveiled some of its security features for Android N that would both prevent “Stagefright” vulnerabilities from happening again and limit the capabilities of the software bugs that the Android team misses.

Last year, security researchers discovered some vulnerabilities in Android’s media library called “libstagefright” that could affect close to a billion Android users. Since then, several other related vulnerabilities have been found, which seems to have prompted Google to find a better solution than just continuing to patch them every other month.

Code Sanitization

Google’s approach is two-fold. It is focused on prevention by sanitizing the code at compilation, and and it's also focused on sandboxing and limiting the privileges of the mediaserver library to minimize the damage of future vulnerabilities.

The company said that enabling the integer overflow checks in its LLVM/Clang compiler toolchain gave the mediaserver team more work because it then had to fix all of those bugs, most of which were not exploitable. However, Google added that if this would’ve been done early on, it could have prevented the majority of the Stagefright bugs. The company also said that some of the overflows were kept for performance reasons, but they were verified and marked as safe to prevent the runtime abort in the compiler.

This sanitization method seems quite effective at preventing these types of bugs, but some vulnerabilities may still sneak past the Android team in shipping code. That’s why Google is also adding sandboxing for the mediaserver.

Sandboxing

In Android M and previous versions, most media-related vulnerabilities had access to too many resources and capabilities by default, including the camera, microphone, graphics, phone, Bluetooth and internet.

Google’s analysis of the Stagefright bugs showed that most of them were related to parsing file formats and codecs. Doing those tasks while optimizing for speed is difficult, and it can lead to accidental vulnerabilities.

The Android team rearchitected the mediaserver library so that it doesn’t need too many permissions to handle the file formats and codecs, thus adhering to the principle of “least privilege.” In the new version of the mediaserver library, parsing code gets few or no permissions.

The other components that require more sensitive permissions have been moved into other sandboxed components that are granted only the necessary permissions. For instance, only the cameraserver gets camera permissions, only the DRM servers gets DRM permissions, and so on.

The libstagefright library is now run within the mediacodec sandbox in Android N and gets very few permissions. Access to camera, microphone, photos, phone, Bluetooth and internet now are disallowed by SELinux, whereas interaction with the kernel has also been further restricted by seccomp, an application sandboxing feature for Linux kernels. Compromising the libstagefright library in Android N would give the attacker fewer capabilities than before and less access to the kernel.

The Android team said that the same hardening techniques that were applied to the media framework could also be applied across the Android codebase. The team is now working on improving the security of other components in Android in the same way.

Lucian Armasu is a Contributing Writer for Tom's Hardware. You can follow him at @lucian_armasu. 

Follow us on FacebookGoogle+, RSS, Twitter and YouTube.

  • hellwig
    I wonder if people understand the impact of these sorts of changes. Look at the code example, it took one assembly instruction and turned it into multiple instructions include three comparisons and a conditional branch.

    Yes it's safer, but it's a LOT more complex. Imagine if it injected this code for EVERY arithmetic operation. They even admit they left some overflows alone for "performance", does that mean they're now performing assembly-level reviews on their applications?
    Reply
  • wifiburger
    I remember codding in my C++ class and our group has to protect every function from overflow attacks, It was stupid, annoying and time consumming
    Reply