ASLR Apocalypse: ‘AnC’ Attack Bypasses ASLR On At Least 22 CPU Microarchitectures

AnC reducing the entropy of data pointers in browsersAnC reducing the entropy of data pointers in browsersFive security researchers from the Vrije University in the Netherlands have developed an attack that can bypass address space layout randomization (ASLR), one of the most important security mechanisms in modern operating systems. The attack affects at least 22 CPU microarchitectures, including some from Intel, AMD, and several ARM chip makers such as Samsung, Nvidia, and Allwinner.

ASLR Protection

ASLR randomizes the location of an application’s code and data in the system’s memory to make it difficult for a potential attacker to compromise that application or the system itself. ASLR has been broken before, but it has still been believed to be a good defense for browsers, according to the Dutch researchers.

Last year, the researchers showed that a JavaScript-enabled attacker can break Microsoft Edge’s ASLR protection through a side-channel vulnerability. Microsoft patched the specific vulnerability that allowed the attack to work by disabling Edge’s memory deduplication feature.

However, the researchers later discovered that the ASLR protection is limited because of the way current CPU microarchitectures manage memory. This allowed them to create an attack that can fully derandomize ASLR from JavaScript without relying on a particular software feature, as was the case with the Edge attack.

The AnC Attack

According to the Dutch researchers who developed the AnC attack, the same cache hierarchy that is used by the memory management units (MMUs) of the CPU to efficiently execute code is also shared by untrusted code in a browser, such as JavaScript.

This set-up allows side-channel attacks to detect which memory locations are accessed during a page table walk performed by the MMU. According to the researchers, the AnC attack is able to find the offsets accessed by the MMU for all of the four-page table pages. The offset within each page breaks nine bits of entropy, which means that even a “perfect” ASLR implementation with 36 bits of entropy is not safe.

The researchers implemented the AnC attack both natively, which allowed them to test it on 22 different CPU microarchitectures, as well as in JavaScript, where they tested it in the Chrome and Firefox browsers.

Precise JavaScript Timers

The AnC attack requires a precise timer in JavaScript to tell the difference between cached and uncached memory access. The major browsers have recently broken the precise timer in JavaScript to prevent other cache attacks that would utilize it.

The Dutch researchers said that they built two new timers that bypass this mitigation, allowing them to not only make the AnC attack possible, but also to revive older cache attacks that now work as well.

Making AnC Work On 22 CPU Architectures

The researchers noticed that various CPU microarchitectures implement page table caches with different behaviors, so they would need to flush the caches to make the AnC attack work reliably on all of them. However, these caches are not properly documented, so they had to reverse engineer the properties of the page table caches for each one of those 22 microarchitectures.

The Dutch researchers’ reverse engineering work benefits not just the AnC attack, but also all the other cache attacks out there that needed to flush these caches on all of the 22 CPU microarchitectures. One of these attacks is the RowHammer attack, which manipulates page tables by exploiting a DRAM flaw.

Mitigation Is Limited Without New Hardware Architectures

The Vrije University researchers found that AnC works on “only” these 22 CPU architectures, because those were the only ones they tested. However, it’s likely that the attack works on many more, potentially covering all existing CPUs. According to them, the attack worked on every single microarchitecture they tried, which doesn’t leave much optimism for the ones they didn’t.

The researchers, as well as a few browser vendors, agreed that ASLR is no longer a good enough defense for browsers.

AnC exploits the way current microprocessors run code efficiently, so until this architecture is overhauled, there isn’t a quick solution that can protect everyone. Eventually, browser vendors may come up with some other mechanisms to avoid this. However, this may be quite difficult to achieve, as the attacks exploit a hardware feature, rather than a software one. Typically, hardware flaws can bypass all software protections.

Until browser vendors come up with a solution to mitigate the attack, if such a solution is even possible, users can do one thing to stop most of the potential attacks that could come through the browser. That solution includes using NoScript or a similar add-on that disables JavaScript in their browsers. However, this comes with a high cost these days, as many websites require JavaScript to run properly.

A Billion Android Devices More Vulnerable To Stagefright Than Ever

Something to note is that Google said ASLR protection would be enough to stop the Stagefright attacks soon after the vulnerability was made public. Even if that were true (and it eventually turned out it wasn't, for most Android devices, anyway), anti-exploit solutions such as ASLR are still only a temporary protection. The long term solution should always be patching the devices. However, because of Android's long-term update problem, and because of the carelessness of Android manufacturers, roughly a billion users with old Android phones will now be vulnerable to Stagefright attacks enabled by the ASLR-bypassing AnC attack.

Google will probably try to stop the attacks utilizing these exploits with its own  "Verify apps" anti-malware service. However, it will essentially be a cat-and-mouse game between attackers finding new ways to use the attack and Google trying to figure out the new attacks before they do too much damage (not unlike the typical malware vs antivirus cat-and-mouse game).

An Increasing Focus On Devastating Hardware Flaws

AnC is one of the last few major attacks that exploit hardware flaws, which can’t be fixed without changing the underlying hardware in significant ways. Some of these recent hardware attacks include RowHammer, the attack that exploits the high-cell density in modern DRAM; BadUSB, which can allow malware to reprogram the embedded firmware in USB devices, and then further spread itself to other computers; or “Jump over ASLR,” a recent hardware flaw found in Intel’s branch predictors, that also allows attackers to bypass the ASLR protection.

Until more recently, there hasn’t been that much research that goes into how secure our chip architectures are, in part because it’s much more difficult to find a vulnerability without reverse engineering parts of the hardware. Not all chip makers offer good documentation for their chips, especially for the latest generations. This makes it difficult for researchers to even understand how the chips work, let alone find security vulnerabilities in them.

The other side is that hardware flaws have been believed to be much rarer because there are fewer opportunities to make a mistake at a low level. However, as shown by the AnC or RowHammer attacks, sometimes a chip's very design makes it vulnerable to certain attacks.

Hardware flaws may require more research work and funds, but when the flaws are discovered, the impact is usually much more significant as well. Some of the hardware flaws, such as the ones mentioned above, can affect almost everyone, bypass most if not all software protections, and take many years for most people to mitigate them by simply buying new hardware. This makes hardware flaws a much better target for both security researchers and malicious attackers.

This thread is closed for comments
    Your comment
  • sadsteve
    Would running noscript in your browser prevent this?
  • lorfa
    Definitely worse than an ASMR apocalypse.
  • mavikt
    NoScript is your friend!