What You Need to Know About the Meltdown and Spectre CPU Flaws
The computer industry is racing to deal with several new vulnerabilities that affect the majority of processors in modern computers and mobile devices. The flaws enable new attacks that break the critical memory defenses in operating systems and bypass fundamental isolation layers, including those vital to virtualization and container technologies.
The most serious of the flaws, dubbed Meltdown or CVE-2017-5754, allows applications running in userspace to extract information from the kernel’s memory, which can contain sensitive data like passwords, encryption keys and other secrets. The good news is that Meltdown can be largely mitigated through software patches, unlike two other vulnerabilities known collectively as Spectre (CVE-2017-5753 and CVE-2017-5715) that will require CPU microcode updates and will likely haunt the industry for some time to come.
Both Meltdown and Spectre stem from a performance-related feature of modern CPUs called speculative execution. This comes into play when a processor reaches a conditional branch in a program’s control flow. Instead of entering an idle state and waiting to see the path the program will take, the CPU uses internal algorithms to guess the most likely path and to execute instructions in advance. If it later turns out the chosen path was incorrect, the speculative execution results are discarded before making them available to the system, and the CPU resumes execution down the correct path.
What researchers from several organizations have independently discovered over the past year is that certain observations can be made about the speculative execution results by monitoring operation timings in the CPU’s cache and those observations can be used to reconstruct data. This kind of leak is not new and is known as a cache timing side-channel.
Meltdown is a particular method of exploiting this CPU feature that is combined with a privilege escalation issue that primarily affects Intel CPUs, but also a few ARM processors. It was discovered independently by three teams: Jann Horn of Google Project Zero; Werner Haas and Thomas Prescher of Cyberus Technology; and Daniel Gruss, Moritz Lipp, Stefan Mangard and Michael Schwarz from the Graz University of Technology.
The team from the Graz University of Technology had previously proposed a new way of isolating kernel and userspace memory in order to protect from hardware-based attacks against the Kernel Address Space Layout Randomization (KASLR), a security defense that makes exploitation of entire classes of vulnerabilities harder.
Their new method was dubbed KAISER, short for kernel address isolation to have side-channels efficiently removed, but while being implemented in the Linux kernel, it was renamed to Kernel Page Table Isolation (KPTI). As it happens, even though it was intended as KASLR hardening, KPTI also mitigates Meltdown.
KPTI is present in the latest stable version of the Linux kernel, 4.14.11, released on Jan. 2, but has yet to be backported to long-term supported (LTS) releases like 4.9.x or 4.4.x. If you’re running a Linux-based system, please make sure you update your kernel as soon as the KPTI patches land for your version.
Microsoft has also released patches for Windows clients and servers, but they might cause conflicts with certain antivirus products. If your security product is not compatible, you will have to either disable it or get a compatibility fix for it from its developer before deploying Microsoft’s Meltdown fixes. There’s a registry setting you can check and a compatibility list maintained by security architect Kevin Beaumont.
Apple has also developed its own Meltdown mitigation, and has released it as part of macOS 10.13.2. The company will release additional patches for Safari and macOS to mitigate the Spectre flaws.
The problem with KPTI is that it will have an impact on system performance for workloads that involve many system calls and interrupts. I/O intensive tasks such as databases will also be affected. Tests are still being run to determine the exact impact for different applications, but for most use cases the performance hit is not expected to be significant.
“It is key that people—from consumers to enterprise IT organizations—apply the security updates they receive,” said Denise Dumas, vice president of Operating System Platform at Red Hat. “Because these security updates may affect system performance, Red Hat has included the ability to enable them selectively in order to better understand the impact on sensitive workloads.”
Meltdown also has serious security implications for virtualized environments and container technologies like Docker, LXC and OpenVZ that share the same kernel. Xen, VMware, QEMU, Citrix and Red Hat have all released security advisories or blog posts describing the impact on their virtualization software.
Large cloud providers like Amazon AWS, Google Cloud, Microsoft Azure, Rackspace and DigitalOcean have also released advisories and scheduled maintenance windows to apply the patches where necessary. Customers are advised to install patches in their guest OSes.
The Spectre attacks are more generic and the variants demonstrated so far have only been used to trick other applications, rather than the kernel, into exposing their own memory and secrets. Forcing applications like browsers to leak passwords and other sensitive info has serious implications and is not addressed by KPTI.
Compared to Meltdown, the Spectre flaws affect many more CPUs from all vendors, including Intel, AMD and ARM. AMD said that Meltdown doesn’t affect any of its processors and that one variant of Spectre has “a near zero risk of exploitation” on its CPUs due to architectural differences.
Addressing Spectre completely will be a longer-term effort and will involve deploying CPU microcode patches that need to be distributed by computer OEMs, as well as OS and application-specific patches, like those for browsers. It’s also worth pointing out that the two Spectre variants demonstrated so far might not be the only ways to abuse the speculative execution feature and researchers are likely to come up with improved techniques in the future. Ultimately, this performance mechanism might have to be revisited and redesigned or removed in future generations of processors.
“Software isolation techniques are extremely widely deployed under a variety of names, including sandboxing, process separation, containerization, memory safety, proof-carrying code,” researchers said in the Spectre white paper. “A fundamental security assumption underpinning all of these is that the CPU will faithfully execute software, including its safety checks. Speculative execution, unfortunately, violates this assumption in ways that allow adversaries to violate the secrecy (but not integrity) of memory and register contents. As a result, a broad range of software isolation approaches are impacted.”
Google, Digital Ocean, Microsoft, and Red Hat are sponsors of The New Stack.
