Skip to main content

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

AnC reducing the entropy of data pointers in browsers

Five 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.

  • sadsteve
    Would running noscript in your browser prevent this?
  • lorfa
    Definitely worse than an ASMR apocalypse.
  • mavikt
    NoScript is your friend!
  • bit_user
    I think I get why this is important, but the author should take an extra paragraph and explain it. As I understand it, ASLR is not an exploit, in and of itself, but rather a protection used to guard against certain other exploits. The effect of breaching it simply removes a layer of defense.

    19303597 said:
    Definitely worse than an ASMR apocalypse.
    I searched, but didn't see a good explanation of that exploit. What does it stand for?

    Anyway, I don't like where this is headed:
    Microsoft patched the specific vulnerability that allowed the attack to work by disabling Edge’s memory deduplication feature.
    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.
    “Jump over ASLR,” a recent hardware flaw found in Intel’s branch predictors, that also allows attackers to bypass the ASLR protection.
    Basically, these attacks are undermining all of the hardware & software tricks to make CPUs & Javascript fast. I worry that if browser and OS developers really took all these exploits seriously, we could experience performance regressions of a decade or more.
  • problematiq
    19302906 said:
    Would running noscript in your browser prevent this?

    It would assuming you didn't download something and run it.
  • Giroro
    Unfortunately, as programming languages get more sophisticated, computer scientists and software engineers lose track of what the computer is actually doing.

    This is also a major contributor to why software is getting exponentially more bloated. Even though x86 has been the defacto standard in PCs for years, most newer programmers don't even have a basic understanding of the architecture's instruction set. You can't trust someone like that to properly secure or optimize their code, so that work falls on the OS and compiler, respectively.
  • targetdrone
    Don't worry folks, it is still perfectly safe to buy that WiFi enable toilet you can flush from your smartphone while at work, no hacker will ever use it for evil purposes.
  • sam1275tom
    So will it still have system-wide effect as today's browsers are not running as administrator or root?
    Also, didn't NX-bit protect this?
  • bit_user
    19310530 said:
    So will it still have system-wide effect as today's browsers are not running as administrator or root?
    Also, didn't NX-bit protect this?
    This "exploit" has nothing directly to do with root or NX bit. However, they're related.

    Basically, address randomization is a technique to prevent people from using buffer overflows and other tricks, in order to modify program memory. When you use a buffer overflow exploit, it's with a goal in mind. The objective is to write some specific block of data in a specific location, in order to take control of the program. So, you need to know the relative location of the target memory block. Address randomization obscures this, breaking most of these exploits. What they showed is how an array of tricks can be used to determine the memory map, which you can then use to re-enable other exploits involving buffer overflows, etc.

    Now, NX bit and access privileges are both additional layers of protection. NX bit shuts down most code modification exploits, but not in all cases. Not running your browser as admin/root limits the extent to which it can compromise the rest of the system (unless combined with a privilege escalation exploit).

    Security is all about layers of protection. Basically, you just want to be difficult enough to hack that it's not worthwhile. Perfect security is an illusion.
  • ZolaIII
    Actually this remaindes me of so called "Quadrooter" CVE's (actually two of them). As a matter a fact it reminds me so much that this is a probably a reason why QC SoC's aren't listed hire. The thing is it doesn't have to come to the ASLR, it can be prevented on earlier layers by more tightened access control privileges & better verification, which actual quadrooter showed us & by the way implementation whose fairly simple.
    Think autor needs to explain the cause how exploit comes to be used much better rather than that it can bypass a certain security mechanism.