Hardening the media stack

Posted by Dan Austin and Jeff Vander Stoep, Android Security team

To help make Android more secure, we encourage and reward researchers who discover vulnerabilities. In 2015, a series of bugs in mediaserver’s libstagefright were disclosed to Google. We released updates for these issues with our August and September 2015 security bulletins.

In addition to addressing issues on a monthly basis, we’ve also been working on new security features designed to enhance the existing security model and provide additional defense in-depth. These defense measures attempt to achieve two goals:

• Prevention: Stop bugs from becoming vulnerabilities
• Containment: Protect the system by de-privileging and isolating components that handle untrusted content

Prevention

Most of the vulnerabilities found in libstagefright were heap overflows resulting from unsigned integer overflows. A number of integer overflows in libstagefright allowed an attacker to allocate a buffer with less space than necessary for the incoming data, resulting in a buffer overflow in the heap.

The result of an unsigned integer overflow is well defined, but the ensuing behavior could be unexpected or unsafe. In contrast, signed integer overflows are considered undefined behavior in C/C++, which means the result of an overflow is not guaranteed, and the compiler author may choose the resulting behavior—typically what is fastest or simplest. We have added compiler changes that are designed to provide safer defaults for both signed and unsigned integer overflows.

The UndefinedBehaviorSanitizer (UBSan) is part of the LLVM/Clang compiler toolchain that detects undefined or unintended behavior. UBSan can check for multiple types of undefined and unsafe behavior, including signed and unsigned integer overflow. These checks add code to the resulting executable, testing for integer overflow conditions during runtime. For example, figure 1 shows source code for the parseChunk function in the MPEG4Extractor component of libstagefright after the original researcher-supplied patch was applied. The modification, which is contained in the black box below, appears to prevent integer overflows from occurring. Unfortunately, while SIZE_MAX and size are 32-bit values, chunk_size is a 64-bit value, resulting in an incomplete check and the potential for integer overflow. In the line within the red box, the addition of size and chunk_size may result in an integer overflow and creation of buffer smaller than size elements. The subsequent memcpy could then lead to exploitable memory corruption, as size + chunk_size could be less than size, which is highlighted in the blue box. The mechanics of a potential exploit vector for this vulnerability are explained in more detail by Project Zero.

Figure 1. Source code demonstrating a subtle unsigned integer overflow.

Figure 2 compares assembly generated from the code segment above with a second version compiled with integer sanitization enabled. The add operation that results in the integer overflow is contained in the red box.

In the unsanitized version, size (r6) and chunk_size (r7) are added together, potentially resulting in r0 overflowing and being less than size. Then, buffer is allocated with the size specified in r0, and size bytes are copied to it. If r0 is less than r6, this results in memory corruption.

In the sanitized version, size (r7) and chunk_size (r5) are added together with the result stored in r0. Later, r0 is checked against r7, if r0 is less than r7, as indicated by the CC condition code, r3 is set to 1. If r3 is 1, and the carry bit was set, then an integer overflow occurred, and an abort is triggered, preventing memory corruption.

Note that the incomplete check provided in the patch was not included in figure 2. The overflow occurs in the buffer allocation’s add operation. This addition triggers an integer sanitization check, which turns this exploitable flaw into a harmless abort.

Figure 2. Comparing unsanitized and sanitized compiler output.

While the integer sanitizers were originally intended as code hygiene tools, they effectively prevent the majority of reported libstagefright vulnerabilities. Turning on the integer overflow checks was just the first step. Preventing the runtime abort by finding and fixing integer overflows, most of which are not exploitable, represented a large effort by Android's media team. Most of the discovered overflows were fixed and those that remain (mostly for performance reasons) were verified and marked as safe to prevent the runtime abort.

In Android N, signed and unsigned integer overflow detection is enabled on the entire media stack, including libstagefright. This makes it harder to exploit integer overflows, and also helps to prevent future additions to Android from introducing new integer overflow bugs.

Containment

For Android M and earlier, the mediaserver process in Android was responsible for most media-related tasks. This meant that it required access to all permissions needed by those responsibilities and, although mediaserver ran in its own sandbox, it still had access to a lot of resources and capabilities. This is why the libstagefright bugs from 2015 were significant—mediaserver could access several important resources on an Android device including camera, microphone, graphics, phone, Bluetooth, and internet.

A root cause analysis showed that the libstagefright bugs primarily occurred in code responsible for parsing file formats and media codecs. This is not surprising—parsing complex file formats and codecs while trying to optimize for speed is hard, and the large number of edge cases makes such code susceptible to both accidental and malicious malformed inputs.

However, media parsers do not require access to most of the privileged permissions held by mediaserver. Because of this, the media team re-architected mediaserver in Android N to better adhere to the principle of least privilege. Figure 3 illustrates how the monolithic mediaserver and its permissions have been divided, using the following heuristics:

• parsing code moved into unprivileged sandboxes that have few or no permissions
• components that require sensitive permissions moved into separate sandboxes that only grant access to the specific resources the component needs. For example, only the cameraserver may access the camera, only the audioserver may access Bluetooth, and only the drmserver may access DRM resources.

Figure 3. How mediaserver and its permissions have been divided in Android N.

Comparing the potential impact of the libstagefright bugs on Android N and older versions demonstrates the value of this strategy. Gaining code execution in libstagefright previously granted access to all the permissions and resources available to the monolithic mediaserver process including graphics driver, camera driver, or sockets, which present a rich kernel attack surface.

In Android N, libstagefright runs within the mediacodec sandbox with access to very few permissions. Access to camera, microphone, photos, phone, Bluetooth, and internet as well as dynamic code loading are disallowed by SELinux. Interaction with the kernel is further restricted by seccomp. This means that compromising libstagefright would grant the attacker access to significantly fewer permissions and also mitigates privilege escalation by reducing the attack surface exposed by the kernel.

Conclusion

The media hardening project is an ongoing effort focused on moving functionality into less privileged sandboxes and further reducing the permissions granted to those sandboxes. While the techniques discussed here were applied to the Android media framework, they are suitable across the Android codebase. These hardening techniques—and others—are being actively applied to additional components within Android. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at security@android.com.