alphaspirit - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

How can attacks bypass ASLR protection on Intel chips?

An Intel chip flaw lets attackers bypass ASLR protection on most operating systems. Expert Michael Cobb explains the vulnerability and how to prevent attacks.

Researchers discovered an Intel chip flaw that can allow attackers to bypass ASLR protection and improve the effectiveness of attacks on any platform. What exactly is the flaw and how does it result in attacks? What can enterprises do to prevent these attacks?

Address space layout randomization (ASLR) first appeared in computer operating systems in the early 2000s and was trumpeted as a major defense against buffer overflow attacks, a technique favored by hackers that can lead to arbitrary code execution and control hijacking. ASLR randomizes the memory locations used by system files and key program components, making it much harder for an attacker to correctly guess the location of a given process while substantially reducing the chances of a buffer overflow attack succeeding. ASLR-based defenses are widely adopted in all major operating systems, including those running on smartphones.

Being able to bypass ASLR memory protection can lead to complete control of a device. In a recent paper entitled "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR," researchers described a side-channel attack that could recover kernel address space layout randomization in about 60 milliseconds. The attack technique centers on Intel's use of the branch target buffer (BTB) in its Haswell chips. A circuit called a branch predictor, used by modern CPUs to improve the flow in the instruction pipeline, anticipates the addresses where soon-to-be-executed instructions are located. The predictor's BTB stores addresses from recently executed branch instructions so they can be obtained directly from a BTB lookup. As correct and incorrect predictions take slightly different amounts of time, this side-channel information can be used to identify the memory locations where specific chunks of code spawned by other software are loaded, as the BTB is shared by several applications executing on the same core.

The researchers said software countermeasures don't address the root cause of this side-channel, as it's the underlying hardware BTB addressing mechanism that requires fixing to prevent exploitable collisions in the BTB. While this attack is more efficient and direct than previous research into ways to bypass ASLR, it requires the attacker to be in a position to already run arbitrary code on the device. If an attacker can run arbitrary code on a system, they have far better options to subvert it than to bypass ASLR.

ASLR is not a perfect defense as implementations vary across operating systems and use different amounts of entropy, which affects the randomness of the address spaces and randomizing memory addresses at different intervals. Also, ASLR is an exploit mitigation technology aimed at protecting devices against remote attacks and not local attacks, which this particular attack is. Mitigation techniques against local attacks involve standard system hardening, such as removing unnecessary programs and accounts and setting up intrusion detection systems. This attack worked against the prediction hardware in Intel Haswell processors, but it's not known whether later Intel processors are also vulnerable. However, it does show that hardware and software play a role in keeping systems resilient from attack.

Next Steps

Find out how your enterprise can mitigate ASLR bypass flaws

Read about how the LevelDropper app malware gains system level privileges

Learn how to protect your Android device from Metaphor ASLR bypass attacks

This was last published in March 2017

Dig Deeper on Application attacks (buffer overflows, cross-site scripting)

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How does your enterprise prevent ASLR protection bypasses?
ASLR is still an after-the-fact fix. Security must be built in from the beginning, not added as an afterthought, mainly by tricks like ASLR.

Time to go back to 1964 with the release of Bob Barton's Burroughs B5000. These machines were entire system design and built in correctness and security checks. They lost out for the next 50 years to the performance-is-everything thinking of the time.

Now is the time to change that and build machines that are intrinsically secure. The B5000 was a descriptor-based machine. That meant each allocated memory block had a separate descriptor for metadata such as address, length, and type of block. Any access to a block was through descriptors. The hardware checks accesses against the address and length. (Still does this in Unisys Clearpath MCP machines.) Programs that attempted out-of-bounds access or buffer overflow are immediately terminated. This helped legitimate developers produce correct software and stopped hackers immediately. With this technique, the trillions of dollars lost to security breaches in viruses and worms would have been avoided. This is not a case of restricting what programmers can do as has been the thinking of the last 50 years.

Any machines which require raw performance avoiding such tests should be kept off the network as stand-alone machines. In the 1960s scientific processing was huge and business (rest of life) computing significant but not predominant. In 2017, business computing is entrenched in every-day life. Unfortunately, insecure machines are the basis of modern computing.

It is time to change and build security into the most fundamental layers of computing.