New reports indicate that researchers have found new branch prediction processor attacks.
One specific attack focuses completely on a separate part of the processor’s branch prediction system.
Researchers from different universities such as,
- College of William and Mary
- University of California Riverside
- Carnegie Mellon
- Binghamton University
put their resources together and successfully described a new kind of security attack.
This new attack makes use of certain features of the modern processor.
Table of Contents
Certain features like the speculative execution.
This attack uses the speculative execution feature to leak sensitive/private information.
Moreover, it can undermine the existing security boundaries which software applications and operating systems erect in order to protect data that is important.
Is this problem something familiar?
Probably.
Not if one knows about Spectre and Meltdown vulnerability attacks.
Security researchers published their results about these vulnerability attacks earlier this year.
The Meltdown and Spectre vulnerability attacks, along with this new attack, take advantage of modern processors in their ability to perform actions such as speculative execution.
As mentioned before, all of these attacks try to leak sensitive and private information.
Researchers have named the new attack as BranchScope.
The BranchScope attack shares a lot of features with the Spectre attack.
More specifically, the variant 2 of the old Spectre attack.
How?
Well, think of it this way.
Both the Spectre 2 and BranchScope attacks exploit the behavior of modern processors.
In other words, they take advantage of features such as branch predictors that have become so common in modern day processors.
Before we go forward, first let’s discuss on what speculative execution is.
Speculative execution happens when the processor (a modern processor) tries to predict what the user wants.
In other words, it tries to run ahead of where a particular program actually is at the moment.
While doing so, it essentially proceeds to execute instructions even before it can make sure that the particular program will actually run those instructions.
To take an example, let’s say there is a program.
And this program tests whether two separate numbers are equal or not.
Based on the result, it does some action.
And it performs another action if the two numbers are not equal.
In such a scenario, the processor tries to be clever.
It tries to guess the outcome of such a program.
Then it speculatively executes one of the resulting action.
So what’s the benefit of doing that?
Well, let’s explain that a bit too.
If the program runs and it turns out that the “modern” processor actually guessed the wrong result, then the processor just throws away the speculative results.
If we are talking from an abstract perspective, then it is as if the processor never made the wrong guess.
Hence, the speculative execution never took place.
Fundamentally, the processor tries to pick up exactly where it left the program.
And then performs the required action that it should have performed from the beginning.
So how does this play in Spectre’s hands so to say?
Well, Spectre attacks happen for a reason.
As a whole, these Spectre attacks happen because the processor is unable to put things in their original condition.
Or at least, in the condition that they should be in.
But modern processors are something amazing.
They can actually revert the changes by making use of its speculative execution feature in the correct manner.
If it does not, then programs would no little choice other than to stop working in the correct manner.
As it turns out, modern processors don’t revert to their speculative execution so perfectly.
And that can cause problems.
These problems specifically become noticeable when we take a look at the modern processor’s cache.
Features such as speculative execution have the ability to cause the modern processor to actually load data into its cache.
Alternatively, it can also evict related data from its cache.
And here lies the problem.
The cache changes do tend to persist even if the processor has made a bad speculation.
Software developers who write their applications carefully can account for this.
Their applications can detect these processor cache changes.
Then they can use these cache changes to infer quite a bit of secret information.
And one also to consider the fact that any processor’s branch predictor represents one of the core pieces of its features such as speculative execution and the whole related machinery.
There is no doubt about the fact that branch predictors, especially in the latest processors, can become very complex.
In fact, they are very complex.
But if we talk about them in broader terms, more or less they all operate in the same way.
Or a similar way, to be more precise.
First, the processor spends resources to track down the address of the related branch instructions.
It has to find out whether the appropriate actor has taken the branch or not.
Then, if the processor detects that the branch is actually taken, it begins to track the address that belongs to the next instruction that is should execute.
That is what experts call the target of the branch.
Any branch predictor feature provides two predictions which are related in a way.
First, the branch predictor can predict whether the branch in question is taken or not taken.
Secondly, if the branch is taken, then what the actual target is.
Security vulnerabilities such as Spectre 2 and BranchScop both try to take advantage of the branch predictor by exploiting its different parts.
From previous research, most of us already know that Spectre 2 relied on a very specific part.
Security researchers call this part BTB.
Or Branch Target Buffer.
This is kind of a data structure.
It exists within any modern processor.
And its job is to record the related branch target.
If we’re talking about the BranchScope vulnerability then things are a bit different.
It doesn’t rely on Branch Target Buffer.
Rather it leaks information by making use of the actual direction of the related prediction.
It wants to know whether the program will take advantage of the prediction or not.
Processors usually store this prediction in a PHT.
Or Pattern History Table.
The Pattern History Table is responsible for keeping a kind of running score.
A running score?
Of what?
Well, it keeps the running score of any and all recently taken branches.
It tries to remember if a program took those branches or not.
In most cases, we’re talking about a two-bit counter.
This two-counter has four states.
These four states are as follows,
- Strongly not taken
- Weakly not taken
- Weakly taken
- Strongly taken
Every time a program takes a branch, the value of the counter moves toward the state know as strongly taken.
Each time the program does not take the branch, the value of the counter moves toward the state known as strongly not taken.
This is the general design.
And such a design means a very important thing.
It means that any occasional mispredict will not actually modify the final result of the prediction.
In other words, a branch that has a state close to almost always taken would still actually predict as taken.
And that will hold true even if once in a while it is actually occasionally not taken.
So how does the prediction actually change?
Any change would require two mispredicts.
But not just any mispredicts.
They have to be back-to-back.
Such a design has proven itself to provide way better results than something like a one-bit counter.
The one-bit counter is simple.
It can only predict a branch based on what actually took place the last time a program took the branch.
So if an attacker wants to use the Spectre 2 security vulnerability, the attack would simply prime the Branch Target Buffer.
Then the attacker would have to exercise great carefulness in executing various branch instructions.
Why?
Because the attacker wants the Branch Target Buffer to have a predictable content.
The attacker also wants that predictable content to come with a specific target instruction.
This target instruction would, if the processor uses the speculative execution feature on it, disturb the “modern” processor’s cache.
And it would do so in a very detectable way.
After the attacker has victimized the program, the program simply runs and then makes the required branch.
When that is done, the attacker usually checks in order to see if the attack managed to disturb the processor’s cache.
It is the measurement of the above-mentioned disturbance that leaks all the sensitive information.
Compared to that, the new attack is a bit different.
In this attack, the hacker usually primes the Pattern History table.
The attacker also primes the running branch instructions.
Why?
So that the attacker-primed Pattern History Table would always end up assuming that a program took a particular branch or not.
This time, the victim code (again) runs and then makes a branch.
This branch can potentially disturb the Pattern History Table.
After the attacker has ensured all the previous steps, then the attacker moves ahead and runs even more branch instructions of the attacker’s own.
The attacker does that to detect the above-mentioned disturbance to the Pattern History Table.
Perhaps this is a good time to mention that the attack actually knows that the processor has to predict some branches in a specific direction.
That allows the hacker to test in order to observe that the victim’s code has successfully managed to change that prediction.
Readers should know that researchers only studied Intel processors.
They used the above-mentioned attacks in order to leak information that Intel had supposedly protected with the company’s SGX feature.
SGX, here, stands for Software Guard Extensions.
This is another processor feature which users can find on many chips.
The SGX feature is used to carve out a small but important section of code that is encrypted.
There are also sections of data.
And the SGX feature carves them in a way that even the virtualization software and/or operating system can’t manage to access it.
Researchers also described many other scenarios where attackers could use such techniques against,
- Image libraries
- Address space layout randomization
Attackers can also use the same techniques to infer data even in encryption.
Security vulnerabilities such as Spectre 2 have managed to provoke both hardware and operating system changes.
Moreover, manufacturers have also planned even more hardware fixes.
Researchers who have studied the new attack have suggested the same for BranchScope.
They say that manufacturers and software developers will have to make use of a combination of solutions in order to stop BranchScope attacks.
There are already some software applications out there which developers can modify in a way to eliminate branches.
Hence, there is no reason why manufacturers cannot alter their hardware in a way that they are able to partition the data structures related to speculative execution that exist on the processor.
This would likely ensure that one process doesn’t have the opportunity to attack another process and cause a massive disturbance.
But guarding against the BranchScope attack is not really that simple.
As is the case with the Spectre 2 security vulnerability, researchers don’t have a clear idea just how much damage can Spectre 2 cause various types of software applications.
However, in both the cases, researchers have established that the hacker has the need to have the ability to run malicious code on a given victim system.
Knowing that, researchers have concluded that attackers will never use these attacks in order to gain initial entry into a given targeted system.
But these security vulnerabilities show something else very important.
They demonstrate that the community has long assumed the existence of these isolation boundaries that have kept their hardware safe from attacks.
The new security vulnerabilities have rendered these boundaries somewhat permeable.
And all of it is down to advanced processor features such as speculative execution.
This feature is very important for all modern processors to provide high-performance for the lowest buck to users.
Apart from that, the new BranchScope attack shows that hardware security vulnerabilities aren’t limited to Spectre.
In fact, just like Spectre, BranchScope has opened up avenues via which hackers can exploit the processor’s speculative execution.
If we’re talking about the fundamentals again, then readers should know that any modern processor contains several internet states.
These internal states include,
- Branch predictor
- Caches
- Registers
- Store buffers
- And much more.
Features such as speculative execution can modify all of these states.
This is the part where users should know something about a thing called architectural state.
These are actually the parts that the documented and published processor instructions can directly manipulate and expose.
Speculative hardware properly preserves the architectural state.
So why do vulnerability attacks such as BranchScope and Spectre exist?
They exist because manufacturers and software developers haven’t apparently found the way to preserve the non-architectural state fully.
What is the non-architectural state?
These are the parts which basically represent the processor’s implementation details.
These can change from one generation of a family to another generation.
And programs can’t really access these directly.
As some of you might have already guessed, features such as speculative execution depend on the non-architectural state.
Manufacturers have designed features such as speculative execution so that they would take place invisibly.
Hence, they give no indication to the related running program that something is happening behind the scenes.
This results in security vulnerability attacks such as BranchScope and Spectre 2.
Some experts say that it will take years for researchers to finally determine each and every way in which attackers can exploit speculative execution.
And leak sensitive information as a consequence of their attack.
Moreover, it will take researchers even longer before they can develop robust and universal defense systems.
Defense systems that can actually stop such kind of security vulnerability attacks.
Conclusion
No one can debate the fact that it has become harder and harder for hackers to attack computer systems and networks.
In turn, hackers have become more craftier.
Unfortunately, this is a pattern.
A pattern that some have managed to observe in the last 40 years ago.
First, they told us that no one required a login even if all ports were listening.
Then they told us that since all ports were listening, users needed a login.
After that, they blocked a few of the very dangerous ports.
Ports such as Telnet.
But still, all other ports were still listening.
So users still needed a login.
But a longer one.
After that, security personnel blocked all the ports except the very few that users needed.
For those few ports, users still required a login.
And a password.
This is where most people are sitting pretty even today.
Then, we came to know that all services basically hide behind, what the community calls, a reverse proxy.
Hence users required a longer password.
After that, we saw the introduction of two-factor authentication.
This made sure that hackers had a really hard time in blasting the front door and getting in.
So what did hackers do?
They started to hack clients.
And then used these clients as beachheads.
Examples include sending the target user an email with an attached .exe file.
Security personnel blocked those exe files.
Hackers again evolved and went after the web browsers.
Engineers then secured web browsers.
And hackers again trumped them by hacking plugins such as flash and/or PDF reader.
Then, we heard advice to uninstall all nasty plugins.
Hackers again stepped up to the plate and used concepts such as privilege escalation along with buffer overflows to attack clients.
This made software developers even more caution.
And they learned how to write code that had built-in security.
Well, what do we know?
Hackers can now go after CPU vulnerabilities as well.
Where will all this end?