What's the Perfect Crime?

Spectre was in the spotlight of cyber threat news in 2018. Its name is a direct reference to the only agent capable of attacking in that way: a specter. Since every ghost always comes back, Spectre has reappeared! To start talking about it, we have prepared a story and a challenge for you. Can you solve it?

Since 2004 the 3.8GHz Pentium 4 has been allowed to "bump in speed from the already available 6xx line of processors." Computers and devices that work with microchips increased their efficiency. Behind that increased performance, there was an effort to boost pipeline in average cases, reduce memory delays by using caches, and work during delays using speculative execution. That allowed routine processes (such as move data from one memory location to another, or jump to a different address) to be much more efficient. Now, how did this advantage become a vulnerability?

To answer that, we will explain what speculative execution is by referring to Paul Kocher’s talk: Spectre Attacks Exploiting Speculative Execution. In fact, Spectre was brought out into the open for the first time in May 2019 at the 40th IEEE Symposium on Security and Privacy.

A CPU could start a course of action without confirming that it is the correct path. In other words, "having the CPU guess likely future execution directions and prematurely execute instructions on these paths." This means that even before the value that executes an instruction appears, the CPU is already performing it.

This solution responded to the limited number of processes a CPU can execute at the same time. That number is conditioned by each CPU clock cycle. To avoid waiting,

There is no cost in time or resources since the alternative option is to wait for the value to be revealed. Then either the CPU expects data to execute orders or "get ahead of the job" and perform the process before the command. However, over time it was seen that there were security implications from speculative execution. In fact, the CPU was opening a vulnerability on its own: a fault attack hardware was built-in.

One way to change instructions is by taking advantage of Branch predictors. These are architectural units used "to guess where guess where the next instruction, after a branch, will come from." Through them, the CPU speculates whether a conditional branch will be taken and the possible outcome of the instruction if it is executed. If the speculation is wrong, the CPU will reverse all registry contents back to where they were before proceeding.

Now, the CPU performs a legal out-of-bounds, i.e., "the software reads data past the end, or before the beginning, of the intended buffer." The Buffer is a memory piece in the processor that allows returning from cache or temporary memory to complete long-lasting memory addresses. Here is where a security breach is performed. In Kocher’s words, the problem is that:

This vulnerability has been widely known and analyzed. Since 2018, when it first came to light, Intel and AMD, two of the world’s biggest processor companies, "adjusted their microcode to change the behavior of some assembly-language instructions in ways that limit speculation." Their solution was to limit "spaces" in which speculation is allowed. By doing so, they made specific processing moments safer but slower.

A paper published by the University of Virginia concludes that this threat is not over yet. Researchers have "uncovered a line of attack that breaks all Spectre defenses," which means that "billions of computers and other devices across the globe are just as vulnerable today as they were when Spectre was first announced."

Specifications of this new threat can be reviewed in their article (Ren et al., 2021). However, the main risk identified in their study is that Spectre vulnerability is not in the software but in the hardware. Notably, Intel, AMD, and AMR processors use micro-ops to process complex instructions into small micro-op caches. And published research describes "attacks that exploit the micro-op cache as a timing channel to transmit secret information." As a result of those attacks, criminals can leak secrets in three primary settings (see those settings in detail here).

Although this finding is recent and will be publicly discussed this year in June at the International Symposium on Computer Architecture, the team that wrote the paper has already talked to Intel and AMD about their findings. On May 4, an Intel spokesman said: "that existing mitigations were not being bypassed and that this scenario was addressed in its secure coding guidance." Still, that response is disappointing because the problem should not be solved using constant-time programming. Instead, it should be fixed from its source: processors.

We hope you have enjoyed this post, and we look forward to hearing from you. By the way, do you need help with vulnerability management? Contact us!