Researchers Bypass ASLR Protection On Intel Haswell CPUs (softpedia.com)

An anonymous reader writes: "A team of scientists from two U.S. universities has devised a method of bypassing ASLR (Address Space Layout Randomization) protection by taking advantage of the BTB (Branch Target Buffer), a component included in many modern CPU architectures, including Intel Haswell CPUs, the processor they used for tests in their research," reports Softpedia. The researchers discovered that by blasting the BTB with random data, they could run a successful collision attack that reveals the memory locations where apps execute code in the computer's memory -- the very thing that ASLR protection was meant to hide. While during their tests they used a Linux PC with a Intel Haswell CPU, researchers said the attack can be ported to other CPU architectures and operating systems where ASLR is deployed, such as Android, iOS, macOS, and Windows. From start to finish, the collision attack only takes 60 milliseconds, meaning it can be embedded with malware or any other digital forensics tool and run without needing hours of intense CPU processing. You can read the research paper, titled "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR," here.

Comments

Enhanced Mitigation Experience Toolkit

[Anonymous Coward]

The Enhanced Mitigation Experience Toolkit, which is offered by Microsoft for the Windows operating system, provides a software implementation of Address Space Layout Randomization (ASLR), in addition to what is or is not provided in hardware, but that's not all. The software also offers Data Execution Prevention (DEP), Structured Exception Handler Overwrite Protection (SEHOP), Certificate Trust (Pinning) and blocks untrusted fonts. Granted, this is an optional add-on for Windows that requires some expertise on the part of the user to make the best use of, but in knowledgeable hands tools like these can be used to further enhance the security of the system by making it that much harder for attackers to successfully inject executable code into the address space of privileged processes.

Re:ASLR was a dumb idea while it lasted

[Luthair]

Its not actually about running malware. ASLR protects the user against bugs in applications by making it more difficult for attackers to trigger the execution of arbitrary code.

Re:ASLR was a dumb idea while it lasted

[Luthair]

Wrong. ASLR is for legitimate applications (and OS code) which might have unsafe input (e.g. images, webpages, etc.)

+5 realy?, This works against the Win version too

[Anonymous Coward]

It is an exploit of the CPU's cache, a cache collision attack, if your data's location is referenced in the "Branch Target Buffer" cache then it is vulnerable, if you can find the location table random locations are meaningless. As such this threatens all software implementations Windows, Linux, whoever does it they are all vulnerable unless they find and implement a way of avoiding the collision or removing themselves from the cache (at a performance cost).

Remote exploit

[DrYak]

TL;DR: because of this bypass ASLR cannot prevent local privilege escalation. but ASLR can still prevent remote access.

The point of ASLR is that it's not easy to determine where the functions are located in memory.

So, if there's an exploit where you can force code to jump at some specific point in memory, you cannot use this exploit to call the function you want because you don't know where they are.

(e.g.: stack smash. Overrun some temporary buffer that is stored on the stack buffer, up to the point where you can overload the return address. So once a function finished, it's doesn't jump back to the caller [it doesn't return] it jumps instead to the address you've overwritten [it jumps to the next function you want to abuse as part of you exploit] )

2 possible situations:

- You've already managed to get (user-level) shell acces (or at least run any payload of your choosing). You want to escalate privileges up to root. You know of a bug in some kernel piece of code that you can try to exploit. ASLR would prevent you from doing it because you don't know where the piece of code is exactly in kernel memory space. So you run the bypass proposed by the researcher and you obtain a list of where is what.
Now you can run your exploit, and gain root.

- You're outside the machine. You want to get remote access. You know a bug in some code (be it kernel or userspace) that could be exploited. But you need to jump into specific function whose precise location in memory you don't know because of ASLR.

So ASLR won't block local privilege escalation anymore (because when you have local access you could defeat ASLR's randomisations)
But ASLR will still block remote access (without local access, you can't get a map of all ASLR-ised functions you need to inject in your remote exploit).