Members of Google's Project Zero vulnerability research team have challenged a key talking point surrounding the security of Google's Android mobile operating system. To wit, a key exploit mitigation known as address space layout randomization does much less than the company's overworked public relations people say in blocking attacks targeting critical weaknesses in Android's stagefright media library.

As Ars reported beginning in July, a series of vulnerabilities in the libstagefright library made it possible for attackers to remotely execute malicious code on close to one billion Android phones. In the following seven weeks, Google has released updates that either lessen the severity of attacks or directly fix the underlying cause, although many users have yet to receive the fixes, and some probably never will.

Throughout the resulting media storm, Google PR people have repeatedly held up the assurance that the raft of stagefright vulnerabilities is difficult to exploit in practice on phones running recent Android versions. The reason, they said: address space layout randomization, which came to maturity in Android 4.1, neutralizes such attacks. Generally speaking, ASLR does nothing to fix a buffer overflow or similar software bug that causes the vulnerability in the first place. Instead, the defense vastly decreases the chances that a remote-code-execution attack exploiting such bugs will succeed. ASLR does this by loading downloaded scripts in a different memory location each time the operating system is rebooted. If the attacker can't locate the malicious code, the exploit results in a simple crash, rather than a game-over hack.

On Wednesday, Project Zero researchers tested a home-grown stagefright exploit on a Nexus 5 device running an Android 5.x version. The results showed that at best, ASLR will lower the chances their exploit will succeed. Meanwhile, Joshua Drake, the security researcher who first disclosed the critical vulnerabilities in the code library, said Android ASLR does even less to prevent a new custom exploit he has developed from working.

The ASLR shortcomings stem from two root causes. First the randomization offers just eight bits of entropy, meaning there are only 28, or 256, possible locations where attackers can find their malicious payload. Second, the Android mediaserver process that relies on the stagefright library automatically loads after each crash. The Project Zero researchers wrote:

This means that we can take a very straightforward approach to bypassing ASLR. We simply choose one of the 256 possible base addresses for libc.so, and write our exploit and ROP stack assuming that layout. Launching the exploit from the browser, we use javascript to keep refreshing the page, and wait for a callback. Eventually memory will be laid out as we expect, bypassing ASLR with brute force in a practical enough way for real-world exploitation. This is only possible because we can achieve a highly reliable heap-spray to get data we control at a known address, independent of the process randomisation. If we had to brute-force two addresses here, the address of our known data and the libc base, this would be less practical. It's also interesting to note that the mediaserver is a special case, at least on my test phone; it isn't cloned from a zygote process, but is instead directly executed - this means that the address space is re-randomised on every exploit attempt. As a result our brute force is not deterministic, and we can’t put a guaranteed upper-bound on time to exploit. 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; 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 5 seconds, and the chance of success is 1/256 per attempt, this gives us a ~4% chance of a successful exploit each minute. So, while it could be more elegant, reliable and effective to use a more sophisticated technique to exploit this bug without requiring a brute-force; it turns out that it’s not really necessary. It’s not unreasonable for a real-world watering hole attack to get a user to browse a page long enough for the exploit to succeed, especially through in-app adverts using WebView.

Elsewhere in the post, after demonstrating a separate weakness involving a 32-bit memory mapping process included in Android, the author wrote: "I knew that ASLR on 32-bit was always a bit shaky; but I didn't think it was this broken."

Drake, who is vice president of platform research and exploitation at security firm Zimperium, said a proof-of-concept exploit he has yet to release publicly is even more effective at defeating Android ASLR. He said his independently developed attack code had been sitting unreleased for a week or two when he read Wednesday's Project Zero post.

"The Android security team guys have been saying repeatedly in press that ASLR mitigates these vulnerabilities, but I think that this post makes it pretty clear that that's not true," he told Ars. "It may complicate it somewhat but it does not mitigate them. That's the point I wanted to make in writing an exploit. They (the Project Zero researchers) beat me to it."

The take-away from the Project Zero findings isn't that ASLR is some sort of security-theater gimmick. To the contrary, it's absolutely crucial in modern software, especially when it's implemented in ways that provide more entropy and prevent it from hampering the user experience. (The Android ASLR, for instance, could probably be architected in a way that would prevent users from losing audio each time the mediaserver crashed, but that would require a major engineering investment that can't be pulled off in a short-term fix.)

The lesson, rather, is that while ASLR is crucial, it isn't a substitute for fixing the underlying bugs that such defenses are intended to mitigate and then making sure all end users have the patch. Like seat belts in a car, ASLR shouldn't be relied on to justify doing unsafe things. Here's hoping Google's PR team gets the memo.