Spectre and Meltdown are the collective names for three different vulnerabilities found in the processors powering a vast number of the computing devices we rely on, from desktop and notebook PCs through to smartphones and other gadgets. And while many people are aware that these vulnerabilities exist and that tech companies are doing their best to plug the leaky bits of code, many aren't really clear on what the problems are.
What follows is a plain English guide to Spectre and Meltdown.
What are Spectre and Meltdown?
Although there are two names out there, Spectre and Meltdown, we are actually dealing with three different vulnerabilities in computer processors.
Software vulnerabilities are reported and catalogued in a database called Common Vulnerabilities and Exposures, or CVE. When a vulnerability is reported it's given a unique identifier so everyone can be are they are talking abut the same thing when discussing a problem.
In this case, CVE 2017-5753 and CVE 2017-5715 are two flaws that have been collectively branded as Spectre.
CVE 2017-5715 CVE 2017-5753 are described as "Systems with microprocessors utilizing speculative execution and direct (for 2017-5715 ) and indirect (for 2017-5753) branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis".
Meltdown, or CVE 2017-5754, is similar but allows an attacker to conduct side-channel analysis of the data cache.
What's that all mean?
You'll notice that all three vulnerabilities talk about a process called speculative execution. This is where a processor carries out a task ahead of it potentially being needed. It's like when McDonalds used to make burgers ahead of time. Sure, some of the burgers were tossed out but it meant that when you walked into the restaurant that you were served quickly.
Processors do stuff ahead of time, just in case it's needed, in order to boost performance. Some of those guesses don't pan out but CPU makers have become pretty good at predicting what you're going to do in order to make things faster.
You'll also notice that the descriptions discuss branch prediction. Another way to boost processor performance is to guess which way a decision will go ahead of time. Let's head to a coffee shop this time - one where the barista knows you reasonably well.
Most days, you order two different drinks; either a cappuccino or a hot chocolate. The barista can serve you faster if they see you before you order and guess which drink you'll want and start preparing it before you ask. If they guess right - you're served faster. Again, processor makers have become really good at guessing what you'll want when faced with a choice and being ready for the decision.
The Spectre and Meltdown vulnerabilities make it possible for someone to either manipulate the results of those different speculative operations (where the processor is guessing what to do next) or see the outcomes of the wrong decisions that are tossed away.
The Red Hat blog says that with Meltdown "the chip is fooled into loading secured data during a speculation window in such a way that it can later be viewed by an unauthorized attacker".
So, some bad computer code is loaded into a system in such a way as it is executed by the processor and then accessed by the attacker who gets can see data that everyone thought was being run in a secure environment.
In the case of Spectre, it's possible to get a CPU to run computer code from a branch it ordinarily would discard. And this has some potentially nasty consequences.
What's the real impact?
As far as enterprise systems go, the biggest shifts over the last decade or so have been the widespread adoption of virtualisation that has, in turn, driven the migration of systems to the cloud.
With virtualisation, dozens, or even hundreds of systems running on a hypervisor, share common CPU infrastructure. The potential is that an errant program running in one system could hijack or eavesdrop on what's going on with a shared CPU to access secure data running on another virtual system on the same physical hardware.
Think about it - this is one of the biggest nightmare scenarios for cloud providers; the privacy of customer data on shared infrastructure could be compromised.
Chris Goettl, product manager from Ivanti, said "It is a complex issue that, if left untended, will likely come back to bite you later this year. There are a number of moving parts to these vulnerabilities and a lot of complexity to fully resolve them. You can expect threat actors will recognise this fact and expect many environments may not be able to respond before they could possibly exploit them in the wild. There is a lot of PoC [Proof of Concept] code out there for them to learn from".
However, in order for an attacker to use these flaws, they'll need to actually get their code on a system. Ryan Kalember, VP of Cybersecurity Strategy at Proofpoint, said "While the vast majority of computing devices are impacted by these flaws, the sky is not falling. Both vulnerabilities require an attacker to be able to run their code on the device they are attacking".
For home users, the risks, at the moment, seem quite small. The vulnerabilities aren't believed to have been weaponised yet. Most experts agree that email-based attacks are a bigger problem for consumers than a targeted attack exploiting Meltdown or Spectre.
Are the bad guys onto this?
At the moment, there aren't any known in-the-wild attacks out there that exploit Spectre and Meltdown. However, the flaws have been on the industry's radar since around mid last year after they were responsibly disclosed. And that means it's possible well-equipped and motivated threat actors have been working on weaponising the vulnerabilities.
Given the sophistication of an attack that could use these flaws, my feeling is that they are more likely to be exploited by a nation-state actor at the moment. The need to physically infiltrate a system, as code needs to run on the CPU directly, puts it out of reach of many criminal elements that prefer to work remotely in jurisdictions where they are unlikely to face prosecution or extradition.
That said, most of the security reports that are published each year report that the vast majority of attacks, over 95%, occur on unpatched systems where the vulnerability that is exploited was identified and a patch was issued over 12 months ago.
What can we do?
Given these flaws affect pretty much every processor Intel has released over the last two decades as well as the processors in every iPhone, iPad and Apple TV the potential impact is pretty broad.
My advice is that once your operating systems and hardware makers issue patches - install them.
Will we like the remedy?
As I reported earlier today, you will see a performance hit on your computing gear. This is because the software instructions in your operating systems will "(selectively) disable branch prediction hardware whenever a program requests operating system (system call) or hypervisor services, so that any attempt by malicious code to train the predictor won’t carry over into the operating system kernel, the hypervisor, or between untrusted virtual machines running on the same server," according to Red Hat.
In other words, the barista won't start making your drink until they are sure of what you've ordered.
We often think of companies like Intel as being large, autonomous entities that churn out hardware at a relentless pace, and almost devoid of any real humanity.
But here's the thing. The code running on every processor, whether it's made by Intel, AMD, Apple, or anyone else is written by humans. And humans make mistakes.
When talking about operating systems Dr Gernot Heiser, from Data 61, said "Rule of thumb is that for typical software, you are left with between two and five faults per thousand lines of code. If you realise the whole operating system is tens of millions of lines that means there are thousands of bugs whether you like it or not. In typical code like an operating system, experience shows that between 10 and 25% of these faults actually are security exploitable".
So, for every million lines of code running on a CPU, there are, conservatively, 2,000 faults with, again conservatively, about 200 flaws that are security exploitable.
In my mind, that means they question is not if there are security holes in the infrastructure we depend on. The questions are when will they be found and who will find them.
In the case of Spectre and Meltdown, it seems responsible disclosure has come through with the win. But we need to be ready for the time when it's the bad guys attack before the fixes are widely available.