Ian Pratt, Bromium Co-Founder, Speaks on Spectre and Meltdown [Video, Part 1]
- The Intel chip vulnerability triggered Spectre and Meltdown – information leakage vulnerabilities.
- Both let attackers that have execution in some unprivileged user space to read data belonging to other processes, even more privileged ones including the kernel itself.
- Meltdown only effects Intel CPUs, whereas the Spectre vulnerability is present on pretty much all modern CPUs including Intel and AMD, and even different architectures such as ARM.
We asked our founder, Ian Pratt, to talk to us about Spectre, Meltdown and what this means to the industry and to Bromium customers. He also wrote up these notes to accompany the video. This is part one of a three-part series (see part two and part three). We have a blog with information for Bromium customers – the most important thing is to make sure you get the Bromium upgrade before you patch Windows – and we’re here to help if you have additional questions.
Spectre, Meltdown and what this means to computing.
These two vulnerabilities were found via security research by many groups around the world, but primarily Google and Graz University of Tech. They independently started investigating the security consequences of some microarchitectural features (speculative execution and branch predictors) that started being introduced on CPUs 20 years ago with the Pentium Pro, and have become ever more sophisticated in the quest for better performance.
Some information leakage vulnerabilities aren’t a big deal as they don’t give the attacker much control over what is leaked, or perhaps only leak a small number of bytes. Spectre and Meltdown are more serious as although they take some effort to pull off they have the potential to give attackers the ability to read any area of memory they like.
The attacker can’t modify the memory or execution state (hence they can’t use it to directly escalate privileges or “infect” a system), but just by reading the kernel memory they may be able to learn interesting secrets. For example, if they could learn the password hash of the administrator account they might be able to use that to simply log in as the administrator and install whatever malware they like on the system.
Spectre and Meltdown would take some effort to pull off, particularly Spectre.
The demonstrations that have been done so far are slightly contrived proof-of-concepts and executing such attacks in the real world is certainly going to be quite hard as an attacker is going to need to learn a lot of detailed information about the target system. If you’re a big cloud provider with hundreds of thousands of ostensibly identical of systems running sensitive workloads from important customers – alongside random users – then you ought to be taking Spectre and Meltdown very seriously. Someone might put in the effort to learn enough about your systems to pull off an attack.
For typical Enterprise servers, you’ll need to ask yourself whether you allow untrusted code to run on your servers. There are some applications where this is necessary (e.g. a Terminal Server) but for many servers all the code that runs is controlled. For such servers, there’s no need to worry.
Enterprise desktops typically do have untrusted users and run untrusted code from web pages, documents, and so on and they are at risk, but I don’t think Spectre and Meltdown need to be particularly high up a CISOs worry list. There have been other vulnerabilities reported over the last few months which are more potent than Spectre/Meltdown and are more likely to get used by bad guys in attacks. We might one day see Spectre or Meltdown being used by attackers for privilege escalation, but I’d be rather surprised if that day was soon. We’ll of course hear about better proof of concepts by security researchers, but whether it is used by bad guys or not is a different matter.
What the CPU and OS vendors doing about Spectre and Meltdown.
Bugs in the CPU are rare. They are very complex pieces of hardware but the vendors do a fantastic job of avoiding security vulnerabilities, making extensive use of formal methods and serious amounts of testing.
Over the years there have been several bugs discovered. In some cases, its possible for the CPU vendor to issue a microcode update that would be installed on the system as part of a firmware update or OS update and fixes the issue. In other cases, the CPU vendor needs the help of the OS or hypervisor vendor to come up with a workaround for the issue. The worst-case scenario is that the CPU vendor has to issue a recall and replace everyone CPUs, but that hasn’t happened since the infamous Pentium FDIV bug 24 years ago.
Normally the CPU vendor and OS vendors are able to come up with a software or microcode workaround that mitigates the issue. Sometime there is some loss of performance, other times not. In the case of Spectre and Meltdown there are unprecedentedly complex set of software and microcode workarounds that are required to mitigate the problem and make OSs secure.
Microsoft has never done anything like this before: making really major changes to the way that the virtual memory system works in order to be able to work around Meltdown. There are smaller but widespread changes in the kernel to mitigate Spectre, and a microcode update to help. Microsoft has already started making patches available for Windows 7, 8 and 10, but Intel and the system vendors aren’t ready with firmware updates to install new microcode yet.
The Intel-specific Meltdown mitigation patches have performance impacts. The impact is dependent on how new the CPU is and whether or not it supports something called PCIDs which reduce the overhead by avoiding some of the TLB entry flushes that would otherwise occur. The performance impact is very workload dependent as it matters how frequently the applications make system calls. Applications that spend all their time executing in user space will see virtually no overhead (e.g. bitcoin mining). In contrast, a server application like a database does a lot of IO and a lot of system calls and could therefore see overhead of low tens of percent. However, it’s not clear that a database server really needs the Meltdown mitigation enabled as there is likely no untrusted code running.