Meltdown and Spectre

Why is it called Meltdown? The vulnerability basically melts security boundaries which are normally enforced by the hardware.

Why is it called Spectre? The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time.

An Analogy of the Vulnerability

Suppose a regular customer visits the same coffee shop and orders the same caffeinated beverage every morning. Over time, the customer gets to know the baristas, who become familiar with the customer’s order. Seeking to offer good service (and save their valued customer some time standing in line) the baristas eventually decide to begin preparing the customer’s order when they wave at them as they enter through the front door. But one day, the customer changes their order. Now the barista has to throw away the previously prepared coffee and make a new one while the customer waits.

Now, suppose the baristas know the customer’s name, and they like to write that name using a permanent marker on their cup. When they speculatively prepare the usual beverage, they write the customer’s name on the cup. If the customer comes in with a different order, the speculated cup is thrown away along with its contents. But in so doing, the cup’s personally identifiable information is briefly visible to anyone watching.

A More Technical Explanation

The speculative controller (i.e. barrista) is accumulating statistics to estimate the probability of IF clause results. For example, if certain IF clause that compares some variable to zero returned FALSE 100 times in a row, you can predict with high probability that the clause will return FALSE when called for the 101st time, and speculatively move along the corresponding code execution branch even without having to load the actual variable. Makes perfect sense, right? However, the problem here is that while collecting this statistics, BPU does NOT distinguish between different processes for added "learning" effectiveness – which makes sense too, because computer programs share much in common (common algorithms, constructs implementation best practices and so on). And this is exactly what the exploit is based on: this peculiarity allows the malicious code to basically "train" BPU (barrista) by running a construct that is identical to one in the attacked process hundreds of times, effectively enabling it to control speculative execution of the attacked process once it hits its own respective construct, making one dump "good stuff" into the CPU cache

Take Home Message

It’s important to bear in mind that these are early days following the discovery of an entirely new class of system security vulnerabilities, and, as a result, mitigations and associated best practice advice may change over time.

Further, sofware is extremely complex. For example, Google engineers created a proof of concept that can read memory at a rate of 1 MB per second. However, before the attack can be performed, the exploit required initialization that took 30 minutes.

However...

if Google engineers could do that, hackers will be able too – because looking at how advanced some of the ransomware we saw last year was, one might wonder if it was written by folks who Google could not offer the salary or the position they wanted. It's also worth mentioning here that a JavaScript-based POC also exists already, making the browser a viable attack vector for Spectre.

How does this get fixed?

Most security specialists agree that Spectre vulnerability opens a whole slew of "opportunities" for hackers, and that the solid fix can only be delivered in CPU hardware. Which in turn probably means at least two years until first such processor appears – and then a few more years until you replace the last impacted CPU.

Quick Overview of the Infection

Quoted Websites

  • https://danielmiessler.com/blog/simple-explanation-difference-meltdown-spectre/
  • https://www.redhat.com/en/blog/what-are-meltdown-and-spectre-heres-what-you-need-know
  • https://meltdownattack.com/
  • Andre Gostev