Spectre: Google researchers investigating the scope and impact of Spectre attacks have published a document (PDF) confirming that Spectre-type vulnerabilities will continue to exist on computers and that techniques using software will incur a very high performance cost.
Regardless of the cost, according to the research, the software will be inadequate, because some of the Spectre flaws are not fixed by such changes.
The discovery and evolution of the Meltdown and Spectre attacks was arguably one of the biggest in computer security history . It was first revealed last January, and since then new variants have been appearing throughout the year.
Note:
Below we will try to explain the vulnerabilities as simply as possible, but also why changes to the software cannot help. If you don't understand something, don't get frustrated, we will explain it below.
Both attacks rely on discrepancies between a processor's theoretical behavior and documented behavior that depend on programmers and how they write their programs to determine the actual behavior of applications.
Specifically, all modern processors perform something we call speculative execution.
What does this mean? They're making assumptions.
For example, consider a value read from memory with assumptions. If the assumption is true or false, it allows or disallows the execution of an instruction, respectively. If the assumptions are correct, the theoretical results are retained. If they are not, the theoretical results are discarded and the processor repeats the calculation.
Theoretical execution is not an architectural feature of the processor. It is an implementation feature and so is supposed to be completely invisible to the applications running on your computer. When the processor rejects a false assumption, it should be as if it never happened.
What researchers of the Meltdown and Spectre vulnerabilities found is that theoretical execution is not completely invisible, and that when the processor rejects the results, some evidence from the wrong assumptions remains behind.
For example, speculation can change data held in the processor's cache. There are applications that can detect these changes by measuring the time it takes to read values from memory.
Spectre: the attack and countermeasures
This allows the attacker to make the processor assume incorrect values and use cache changes to reveal the true value. This becomes particularly threatening in applications such as web browsers: a malicious JavaScript can use such data to learn about the memory layout of the running process and then use this information to exploit other flaws and execute arbitrary code.
Browser developers assume that they can build secure sandboxes for browser processes to run in. This way, scripts from malicious domains will not be able to learn about the memory layout and running processes. Architecturally, these assumptions are correct. But the reality of Spectre has come and landed many in the ground.
Meltdown and Spectre: the difference
The Meltdown attack, which targeted chips from Intel, Apple , and other manufacturers, was a particularly nasty variation of the above. The vulnerability allows a malicious program to extract data from the operating system kernel. Immediately after Meltdown was discovered, changes were made to operating systems to hide their data from such malicious programs.
However, the Spectre vulnerability has many different variants to date (and continues to be discovered), which makes it much more insidious. So developers are trying with various software development techniques to prevent data leakage in the processor or simply to limit the information that can be revealed through the theoretical execution of the processor.
Google's research has shown that these software-based measures are essentially half-measures. Some of them, such as blocking all assumptions after loading values from memory, protect against many attacks, but are too debilitating on the system to be used in practice.
The researchers experimented with modified versions of the V8 JavaScript engine in Chrome, and using this technique dropped performance by between a third and a fifth.
It should be noted here that no matter how many measures they took, they did not discover anything that provides absolute protection. According to the researchers, a combination of techniques must be used and this will have cumulative effects on performance.
And now what?
So the company concluded that we can't protect against the Spectre vulnerability with software patches alone. Appropriate measures should also be taken in hardware, but this thought is scary because it requires upgrades to millions of systems.
Currently, applications that attempt to build secure environments rely on hardware-provided guarantees for inter-process protection.
For example, Chrome has changed its code to prevent content from running from multiple domains in the same process. This still doesn't protect Chrome's sandbox from a script attack, but it does ensure that a script can't be attacked from multiple domains. However we do it, it's a form of protection...
Overall, the research indicates that Spectre will concern software developers, hardware manufacturers, and end users for years to come.
Good strength..
