Android’s Stagefright vulnerability hardened against exploits

The bug hasn’t been used outside of the lab to compromise a user’s phone, yet it continues to get a lot of attention

Last week Google announced fixes to the widely reported Stagefright vulnerability. Fix might not be the right word, though, because as of April 19, 2016, when Google released the Android Security Year in Review for 2015, the company reported: “As of this writing, we have not observed, nor are we aware of, any successful attempts to exploit the Stagefright vulnerabilities against actual user devices.”

The status of this exploit seems to contradict the many reports of the Stagefright vulnerability, dating to its announcement at the Black Hat security conference last summer. If all were true, Android phones could be expected to spontaneously combust at any moment.

Why Stagefright attracts so much attention

Stagefright received a lot of attention because it is categorized by Android’s security team as critical. It is a classic heap overflow exploit that could result in the remote insertion and execution of malicious code by overwriting dynamically allocated memory when the mediaserver plays a media file such as an MP4 video. Heap overflow vulnerabilities have occurred in many operating systems and apps over the past 20 years. The general class of memory corruption vulnerabilities is well understood by the security and tech communities, so the topic garners headlines.   

Last summer, first impressions of this critical bug were benign because in 2011, Google added Address Space Layout Randomization (ASLR) to Android, which protected almost all devices built since then. ASLR defends against overflow exploits by randomly assigning memory locations to executables. This prevents exploits after an overflow by hiding the memory address from which malicious code would begin execution.

At last year’s Black Hat conference, Joshua Drake of Zimperium presented a test case proving the vulnerability, and in September Mark Brand posted another to Google’s Project Zero blog that confirmed Drake’s work and proved ASLR could be bypassed and code inserted into memory via the parsing of a media file by libstagefright could be remotely executed. Drake probably earned $3,000 or more from the Android Rewards program that pays a bounty to independent security analysts when an exploit is identified.

Brand reported: “I did some extended testing on my Nexus 5, and results were pretty much as expected. In 4096 exploit attempts, I got 15 successful callbacks [think of a callback as a lever that a hacker could use to do something harmful]. The shortest time-to-successful-exploit was lucky, at around 30 seconds, and the longest was over an hour. Given that the mediaserver process is throttled to launching once every five seconds, and the chance of success is 1/256 per attempt, this gives us a ~4% chance of a successful exploit each minute.”

Bug bounties and zero-day exploits

All large software systems have bugs, and some of those bugs could be exploited by bad actors (the industry term for programmers and analysts who intend to do harm). Many companies employ security analysts or offer bug bounties to expose unreported bugs that could result in harmful exploits referred to as zero-day exploits. Bounties are a common method for managing security risks and software quality.

The relationships between software companies such as Google and independent analysts tend to be mutually supportive. Sometimes analysts who present at major security conferences such as Black Hat will prematurely disclose a zero-day exploit to generate PR and attendance at their talks, which creates tension in the relationships. But that is often the exception rather than the rule.

Prevention of future libstagefright exploits

Google described in its blog post how it made a change to the tool chain it uses to compile Android components such as libstagefright. It added a feature called UndefinedBehaviorSanitizer to the C and C++ compiler used to build Android components that can detect heap overflow conditions and abort execution to prevent memory corruption.

It’s clear how this would affect future Android releases, such as Android N currently available as a preview release. But not all devices will get Android N. There are unconfirmed rumors that Google will announce a new updating strategy later this month at its developer conference that might extend its update capabilities.

Containment future libstagefright exploits

With Android N comes a re-architected mediaserver that includes a much more granular approach to granting privileges to components.

The components used to parse media files that perform functions such as decompression and rendering audio and video have been moved into unprivileged sandboxes that have few or no permissions, making it much more difficult than earlier versions for an exploit to inherit all the privileges of the mediaserver.

Components such as the cameraserver, audio server and drmserver that require sensitive permissions are moved into separate sandboxes that only grant each the privileges that are needed by the individual components. Only the cameraserver may access the camera, only the audioserver may access Bluetooth and only the drmserver may access DRM resources. The change is depicted in the chart below.

android mediaserver fix2 Google

Because it is impossible to eliminate bugs, the risk of exploits must be managed. Apple, Microsoft and Redhat all have teams like Google’s that are augmented by independent security researchers who scour their software products, identify and prioritize exploits, and devise patches and prophylactic remediation strategies. Android gets a lot of attention because during its early history, fragmentation left it vulnerable and because the source code is publically available, making it a more interesting subject for researchers to study.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2016 IDG Communications, Inc.