Summary The severe design flaw in Intel microprocessors that allows sensitive data, such as passwords and crypto-keys, to be stolen from memory is real – and its details have been revealed.
On Tuesday, we warned that a blueprint blunder in Intel's CPUs could allow applications, malware, and JavaScript running in web browsers, to obtain information they should not be allowed to access: the contents of the operating system kernel's private memory areas. These zones often contain files cached from disk, a view onto the machine's entire physical memory, and other secrets. This should be invisible to normal programs.
Thanks to Intel's cockup – now codenamed Meltdown – that data is potentially accessible, meaning bad websites and malware can attempt to rifle through the computer's memory looking for credentials, RNG seeds, personal information, and more.
Here's a video demonstrating a Meltdown attack:
Using #Meltdown to steal passwords in real time #intelbug #kaiser #kpti /cc @mlqxyz @lavados @StefanMangard @yuvalyarom https://t.co/gX4CxfL1Ax pic.twitter.com/JbEvQSQraP
— Michael Schwarz (@misc0110) January 4, 2018
On a shared system, such as a public cloud server, it is possible, depending on the configuration, for software in a guest virtual machine to drill down into the host machine's physical memory and steal data from other customers' virtual machines. See below for details on Xen and VMware hypervisor updates.
Intel is not the only one affected. Arm and AMD processors are as well – to varying degrees. AMD insisted there is a "near-zero" risk its chips can be attacked in some scenarios, but its CPUs are vulnerable in others. The chip designer has put up a basic page that attempts to play down the impact of the bugs on its hardware.
Arm has produced a list of its affected cores, which are typically found in smartphones, tablets and similar handheld gadgets. That list also links to workaround patches for Linux-based systems. Nothing useful from Intel so far.
This is, essentially, a mega-gaffe by the semiconductor industry. As they souped up their CPUs to race them against each other, they left behind one thing in the dust. Security.
One way rival processors differentiate themselves, and perform faster than their competitors, is to rely on speculative execution. In order to keep their internal pipelines primed with computer code to obey, they do their best to guess which instructions will be executed next, fetch those from memory, and carry them out. If the CPU guesses wrong, it has to undo the speculatively executed code, and run the actual stuff required.
Unfortunately, the chips in our desktop PCs, laptops, phones, fondleslabs, and backend servers do not completely walk back every step taken when they realize they've gone down the wrong path of code. That means remnants of data they shouldn't have been allowed to fetch remain in their temporary caches, and can be accessed later.
The trick is to line up instructions in a normal user process that cause the processor to speculatively fetch data from protected kernel memory before performing any security checks. The crucial Meltdown-exploiting x86-64 code can be as simple as...
; rcx = kernel address ; rbx = probe array retry: mov al, byte [rcx] shl rax, 0xc jz retry mov rbx, qword [rbx + rax]
Trying to fetch a byte from the kernel address as a user process triggers an exception – but the subsequent instructions have already been speculatively executed out of order, and touch a cache line based on the content of that fetched byte.
An exception is raised, and handled non-fatally elsewhere, while the out-of-order instructions have already acted on the content of the byte. Doing some Flush+Reload magic on the cache reveals which cache line was touched and thus the content of the kernel memory byte. Repeat this over and over, and eventually you dump the contents of kernel memory.
On Wednesday, following research by a sizable collection of boffins, details of three closely related vulnerabilities involving the abuse of speculative execution in modern CPUs were made public:
- CVE-2017-5753: Known as Variant 1, a bounds check bypass
- CVE-2017-5715: Known as Variant 2, branch target injection
- CVE-2017-5754: Known as Variant 3, rogue data cache load
These have been helpfully grouped into two logo'd and branded vulnerabilities: Meltdown (Variant 3), and Spectre (Variants 1 and 2). Both links go to a website with the full technical papers detailing the attacks if you want to see in gory detail how they work.
There is also a Google Project Zero blog post going over the finer points. Finally, here's some proof-of-concept exploit code that runs on Windows.
Here's a summary of the two branded bugs:
- Meltdown
- This is the big bug reported on Tuesday.
- It can be exploited by normal programs to read the contents of private kernel memory.
- It affects potentially all out-of-order execution Intel processors since 1995, except Itanium and pre-2013 Atoms. It definitely affects out-of-order x86-64 Intel CPUs since 2011. There are workaround patches to kill off this vulnerability available now for Windows, and for Linux. Apple's operating systems have also been patched. Installing and enabling the latest updates for your OS should bring in the fixes. You should go for it. If you're a Windows Insider user, you're likely already patched. Windows Server admins must enable the kernel-user space splitting feature once it is installed; it's not on by default.
- Amazon has updated its AWS Linux guest kernels to protect customers against Meltdown. Google recommends its cloud users apply necessary patches and reboot their virtual machines. Microsoft is deploying fixes to Azure. If you're using a public cloud provider, check them out for security updates.
- The workarounds move the operating system kernel into a separate virtual memory space. On Linux, this is known as Kernel Page Table Isolation, or KPTI, and it can be enabled or disabled during boot up. You may experience a performance hit, depending on your processor model and the type of software you are running. If you are a casual desktop user or gamer, you shouldn't really notice. If you are hitting storage, slamming the network, or just making a lot of rapid-fire kernel system calls, you will notice a slowdown. Your mileage may vary.
- It also affects Arm Cortex-A75 cores, which aren't available yet. Qualcomm's upcoming Snapdragon 845 is an example part that uses the A75. There are Linux kernel KPTI patches available to mitigate this. The performance hit isn't known, but expected to be minimal.
- Additionally, Cortex-A15, Cortex-A57 and Cortex-A72 cores suffer from a variant of Meltdown: protected system registers can be accessed, rather than kernel memory, by user processes. Arm has a detailed white paper and product table, here, describing all its vulnerable cores, the risks, and mitigations.
- Meltdown does not affect any AMD processors.
- Googlers confirmed an Intel Haswell Xeon CPU would allow a normal user program to read kernel memory.
- It was discovered and reported by three independent teams: Jann Horn (Google Project Zero); Werner Haas, Thomas Prescher (Cyberus Technology); and Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz (Graz University of Technology).
- Spectre
- Spectre allows, among other things, user-mode applications to extract information from other processes running on the same system. Alternatively, it can be used by code to extract information from its own process. Imagine malicious JavaScript in a webpage churning away using Spectre bugs to extract login cookies for other sites from the browser's memory.
- It is a very messy vulnerability that is hard to patch, but is also tricky to exploit. It's hard to patch because just installing the aforementioned KPTI features is pointless on most platforms – you must recompile your software with countermeasures to avoid it being attacked by other programs, or wait for a chipset microcode upgrade. There are no solid Spectre fixes available yet for Intel and AMD parts.
- In terms of Intel, Googlers have found that Haswell Xeon CPUs allow user processes to access arbitrary memory; the proof-of-concept worked just within one process, though. More importantly, the Haswell Xeon also allowed a user-mode program to read kernel memory within a 4GB range on a standard Linux install.
- This is where it gets really icky. It is possible for an administrative user within a guest virtual machine on KVM to read the host server's kernel memory in certain conditions. According to Google:
When running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM.
- AMD insists its processors are practically immune to Variant 2 Spectre attacks, which siphon data from the kernel. As for Variant 1, you'll have to wait for microcode updates or recompile your software with forthcoming countermeasures described in the technical paper on the Spectre website.
- The researchers say AMD's Ryzen family is affected by Spectre. Googlers have confirmed AMD FX and AMD Pro cores can allow arbitrary data to be obtained by a user process; the proof-of-concept worked just within one process, though. An AMD Pro running Linux in a non-default configuration – the BPF JIT is enabled – also lets a normal user process read from 4GB of kernel virtual memory.
- For Arm, Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73, and Cortex-A75 cores are affected by Spectre. Bear in mind Cortex-R series cores are for very specific and tightly controlled embedded environments, and are super unlikely to run untrusted code. To patch for Arm, apply the aforementioned KPTI fixes to your kernel, and/or recompile your code with new defenses described in the above-linked white paper.
- Googlers were able to test that an Arm Cortex-A57 was able to be exploited to read arbitrary data from memory via cache sniffing; the proof-of-concept worked just within one process, though. Google is confident ARM-powered Android devices running the latest security updates are protected due to measures to thwart exploitation attempts – specifically, access to high-precision timers needed in attacks is restricted. Further security patches, mitigations and updates for Google's products – including Chrome and ChromeOS – are listed here.
- Discovered and reported by these separate teams: Jann Horn (Google Project Zero); and Paul Kocher in collaboration with, in alphabetical order, Daniel Genkin (University of Pennsylvania and University of Maryland), Mike Hamburg (Rambus), Moritz Lipp (Graz University of Technology), and Yuval Yarom (University of Adelaide and Data61).
We're told Intel, AMD and Arm were warned of these security holes back in June last year. Our advice is to sit tight, install OS and firmware security updates as soon as you can, don't run untrusted code, and consider turning on site isolation in Chrome to thwart malicious webpages trying to leverage these design flaws to steal session cookies from the browser process (Firefox has its own mitigations.)
If you are using the Xen hypervisor, you should grab security patches when they become available. Intel and AMD processors are affected, and they're still checking whether Arm is.
"Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests," due to these processor security holes, according to the hypervisor project team. If you've experienced a mass reboot – or are scheduled for one – by your public cloud provider, this may be why.
Meanwhile, VMware's ESXi, Workstation and Fusion hypervisors need patching to counteract the underlying hardware design flaws.
Finally, if you are of the opinion that us media types are being hysterical about this design blunder, check this out: CERT recommends throwing away your CPU and buying an non-vulnerable one to truly fix the issue. ®
Updated to add
CERT has downgraded its advice from "replace CPU" to "apply updates."
