Android's Stagefright is back! Here’s what you need to know

The Android vulnerability known as Stagefright is back in the limelight. Stagefright is a bug, or more accurately a series of similar bugs, in an Android programming library called libstagefright. It is part of the operating system that handles media files such as movies. If you receive an MMS (Multimedia Messaging Service) message that links to a video, or watch a clip embedded in a web page, or download a video for later, your Android will probably load up and use the libstagefright software to play the file. Researchers at Zimperium found a number of memory corruption bugs in the libstagefright code, and prepared a paper for the recent Black Hat conference to talk about them. Presentations at Black Hat that deal with vulnerabilities in widespread devices often get a lot of publicity before the event, and with Zimperium claiming that some 950,000,000 Androids might be at risk, Stagefright got more publicity that most. Eventually, Zimperium didn't release any actual exploits at Black Hat, giving the Android ecosystem a bit more time to get its patches tested and shipped.

Public exploit code

But that was a month ago, and the company has now decided to wait no longer. Zimperium has published a Python program that generates booby-trapped .MP4 movie files, apparently to help you test whether your device is patched. The bad news is that the "test" program doesn't merely prove that you have an exploitable Android, for example by popping up the Android calculator program without asking. (Running CALC.EXE is a standard proof-of-concept in the Windows world.) The test program produces a movie file exploit that calls home to an internet address you specify when you create the file, and gives you a command shell on the victim's Android device. This sort of exploit is known as a "reverse shell" - reverse because the attacked computer connects to you, rather than you logging in to it; shell because that's the Unix-flavoured name for a command prompt. So, as much as Zimperium's Python script is a proof-of-concept, it's also, strictly speaking, a Remote Access Trojan creation kit. (Sophos Anti-Virus detects them as Exp/20151538-A.) The good news is that the exploit seems, at best, to be device specific.

At any rate, the blog article says that: This exploit has several caveats. First, it is not a generic exploit. We only tested it to work on a single device model. We tested this exploit on a Nexus running Android 4.0.4. Also, due to variances in heap layout, this is not a 100% reliable exploit by itself. We were able achieve 100% reliability when delivered through an attack vector that allowed multiple attempts. Finally, this vulnerability was one of several that was neutered by GCC 5.0’s ‘new[]’ integer overflow mitigation present on Android 5.0 and later.

As we explained in a recent article about booby-trapped files (in that article we dealt with a Word-based attack rather than a movie-based one), modern exploits often rely on two tricks. One is known as a spray, where the attacker knows he can crash your device, but is only able to aim control at a general area of memory. So he pads out his attack code, or repeats it over and over, in the hope that when it is loaded by Word, or by libstagefright, or whatever, it's a big enough target in a suitable place. Padding or repeating your attack code is known as spraying memory, for obvious reasons. But operating systems, both by accident and by design, don't always allocate memory in a repeatable or predictable way. The memory available for allocation to a program is known as the heap, and the heap layout will typically vary between different devices, between different versions of the operating system, and even between reboots. As Zimperium points out, this greatly diminishes the chance that its proof-of-concept exploits will work in the real world without modification. The second trick needed by many exploits, including Stagefright, is ROP, or Return Oriented Programming. Thanks to DEP, or Data Execution Prevention, an attacker can't blindly jump to exploit code he has sprayed onto the heap: it's labelled as data, so trying to run it will fail and the exploit will be prevented. 

So, the attacker needs to identify code fragments that are already in executable memory, and string them together as a precursor to his attack. He then creates a list of the addresses at which these fragments are located, and jumps to them in turn. On Intel processors, this "jumping" is usually done by an instruction called RET, short for short for return from subroutine, which is how Return Oriented Programming gets its name. But recent versions of Android, along with every other modern operating system, has a feature called ASLR, or Address Space Layout Randomisation. ASLR does what its name suggests: it loads the components of your program at a different place in memory every time.

Actually, for performance reasons, the locations typically change only when you reboot, but it nevertheless makes every user's memory layout different. ASLR is a great defensive tool against ROP, because it means that the list of code fragment addresses found by an attacker are often valid only on the attacker's own test device. When you send your exploit out into the real world, you may find that instead of making a series of pre-programmed turns that just happen to lead onto the freeway, you end up crashed into a hedge or stuck in a ditch.