Address space layout randomization (ASLR) is a widely-used method that prevents memory corruption attacks by arranging the address space positions of key data areas in a random manner. This technique can be found in the security designs of many applications and well-known operating systems.

But according to new research, it seems there is a new ASLR bypass out there.

A Map to an Unknown Destination

Attackers have bypassed ASLR in the past, but research teams from the State University of New York at Binghamton and the University of California, Riverside teamed up to devise a new ASLR bypass method based on what’s going on in the hardware of the central processing unit (CPU) that runs the code.

In their paper, “Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR,” the researchers described their novel side-channel attack, which focuses on the branch target buffer (BTB) of the CPU. The BTB helps to predict where the next branch of code will be executed, which speeds up a CPU’s throughput.

The paper explained how an attacker could create BTB collisions between two user-level processes (or between a kernel and a user process) in a “controlled and robust manner.” The researchers found that “identifying the BTB collisions allows the attacker to determine the exact locations of known branch instructions in the code segment of the kernel or of the victim process, thus disclosing the ASLR offset.”

The whole point is to learn the offset length generated by the ASLR. It’s like having a map to an unknown destination that points out the way.

According to SecurityWeek, the researchers tested the attack on a Haswell CPU running a current version of Linux. They seemed confident that the attack would also work for Windows and Android. Not only that, but they felt it would work on a Kernel-based virtual machine (KVM), which would open up a new attack vector targeting virtualized computers.

Blocking ASLR Bypass

Some software changes might help here. One option is to switch to a finer-grain ASLR that changes on functions rather than only once during startup. This would at least make the attack harder to perform.

Primary mitigation, however, requires hardware changes. It may be necessary, for example, to change the affected addressing mechanism to prevent these collisions in a BTB. It can also be helpful to use separate indexing functions for user or kernel-level code. Whether the hardware manufacturers think this is serious enough to retool a CPU’s hardware remains to be seen.