• United States



CSO Senior Writer

The second Meltdown: New Intel CPU attacks leak secrets

May 14, 201910 mins

Intel has done some mitigations for these vulnerabilities that can leak secrets from virtual machines, secure enclaves and kernel memory. Here's how the attacks work.

Intel CPU  >  security
Credit: Intel / Baks / Getty Images

Researchers have found new flaws in Intel processors that could allow hackers to defeat the security boundaries enforced by virtual machine hypervisors, operating system kernels and Intel SGX enclaves, putting data on both servers and endpoint systems at risk. The new attack techniques can be used to leak sensitive secrets like passwords or encryption keys from protected memory regions and are not blocked by mitigations for past CPU attacks.

Over a year ago, the Meltdown and Spectre attacks took the computer industry by storm and showed that the memory isolation between the operating system kernel and unprivileged applications or between different virtual machines running on the same server were not as impervious as previously thought. Those attacks took advantage of a performance enhancing feature of modern CPUs called speculative execution to steal secrets by analyzing how data was being accessed inside CPU caches.

Since then, the research community found additional “side channel” techniques that could allow attackers to reconstruct secrets without having direct access to them, by analyzing how data passes through the CPU’s microarchitectural components during speculative execution.

On Tuesday, researchers from several universities and the private sector disclosed new attacks that have the same impact as Meltdown and Spectre and which have been reported privately to Intel over the past year. The difference is these new techniques take advantage of the buffers of Intel CPUs instead of their caches to leak data.

“Unlike existing attacks, our attacks can leak arbitrary in-flight data from CPU-internal buffers (line fill buffers, load ports, store buffers), including data never stored in CPU caches,” researchers from Vrije Universiteit Amsterdam said on a website they set up to share information about the new vulnerabilities. “We show that existing defenses against speculative execution attacks are inadequate, and in some cases actually make things worse. Attackers can use our attacks to obtain sensitive data despite mitigations, due to vulnerabilities deep inside Intel CPUs.”

New attack class: microarchitectural data sampling

Intel calls this new class of attacks microarchitectural data sampling (MDS) and has split the reported issues into four vulnerabilities with distinct CVE numbers:

  • CVE-2018-12126 — microarchitectural store buffer data sampling (MSBDS)
  • CVE-2018-12127 — microarchitectural load port data sampling (MLPDS)
  • CVE-2018-12130 — microarchitectural fill buffer data sampling (MFBDS)
  • CVE-2019-11091 — microarchitectural data sampling uncacheable memory (MDSUM)

Three of these vulnerabilities — MLPDS, MFBDS and MDSUM — are covered in a research paper from the Systems and Network Security Group (VUSec) at Vrije Universiteit Amsterdam. The VUSec researchers refer to their side-channel attack technique as Rogue In-Flight Data Load, or RIDL.

The fourth vulnerability — MSBDS — is covered in a separate research paper authored by researchers from University of Michigan, Worcester Polytechnic Institute, Graz University of Technology, KU Leuven and University of Adelaide. Their technique can leak data from store buffers and has been dubbed Fallout. It can also be used to leak memory information that can help attackers defeat kernel address space layout randomization (KASLR), a security mechanism in operating systems designed to make the exploitation of memory corruption vulnerabilities much harder.

“Ironically, the recent hardware countermeasures introduced by Intel in recent Coffee Lake Refresh i9 CPUs to prevent Meltdown make them more vulnerable to Fallout, compared to older generation hardware,” the researchers said on their website.

Over the course of the past year, some of the same flaws have also been independently found and reported to Intel by other researchers, including Giorgi Maisuradze from CISPA – Helmholtz Center for Information Security in Germany who was an intern at Microsoft Research at the time, a team led by Daniel Gruss at Graz University of Technology, a team led by Dan Horea Lutas at Bitdefender, Volodymyr Pikhur from Oracle and Lei Shi from QiHoo 360.

This highlights the increased interest in the research community for CPU and hardware-related flaws in general and proves once again that different researchers can independently find the same vulnerabilities, which means that attackers can too.

How do the attacks work and who is affected?

The vulnerabilities affect modern Intel CPUs used in servers, desktops and laptops. Intel has published a list of potentially affected CPUs on its website and in a white paper written for software developers.

According to VUSec, after reviewing their paper, AMD and ARM said their CPUs are not affected by these issues.

The flaws can be exploited by a malicious process, such as unprivileged applications or even JavaScript running inside a browser to break memory isolation boundaries and obtain data from other processes.

The VUSec researchers have a proof-of-concept where they use a virtual machine to obtain the contents of the /etc/shadow file from another virtual machine that shares the same physical CPU core — a common setup for multi-tenant cloud environments. In another proof-of-concept the researchers obtain the /proc/version information from the Linux kernel by using an unprivileged process.

Since these are side-channel attacks, data values are not read directly but inferred from how they’re loaded into buffers during the CPU speculative execution. Speculative execution is designed to execute instruction paths in advance before they’re required by a process to speed up its operation.

It’s based on an algorithm that attempts to guess which execution path a program will take in its code before the program actually takes it. If the assumption is wrong, the generated data is normally discarded and execution continues down the correct path. However, this also creates an opportunity for a local attacker to infer information about that data while it lives in caches or, in this case, buffers.

“RIDL stems from micro-optimizations that cause the CPU to serve speculative loads with extraneous CPU-internal inflight data,” the VUSec researchers said in their paper. “In essence, RIDL puts a glass to the wall that separates security domains, allowing attackers to listen to the babbling of CPU components.”

Herbert Bos, professor of Systems Security at VU Amsterdam, tells CSO that there are two methods of obtaining the data: either collecting everything indiscriminately and then sifting through it in an attempt to understand it and extract interesting pieces, or by forcing the victim process to access the exact data the attacker is actually interested in.

For example, in their VM proof-of-concept attack, the researchers repeatedly opened SSH connections and attempted to authenticate as root. Each of those attempts forced the OS in the targeted virtual machine to access the /etc/shadow which contains password hashes for the accounts on the systems.

It took around 24 hours of such activity to leak enough information to rebuild the whole file, but in other MDS attack scenarios the targeted data could be recovered in milliseconds. It really depends on what the attacker is trying to achieve and how they choose to do it, Bos explains.

How to mitigate MDS attacks

“Microarchitectural Data Sampling (MDS) is already addressed at the hardware level in many of our recent eighth- and ninth-generation Intel Core processors, as well as the second-generation Intel Xeon Scalable Processor Family,” Intel said in an emailed statement. “For other affected products, mitigation is available through microcode updates, coupled with corresponding updates to operating system and hypervisor software that are available starting today. We’ve provided more information on our website and continue to encourage everyone to keep their systems up to date, as it’s one of the best ways to stay protected.”

The CPU microcode updates add a new instruction that OS and software developers can use to overwrite buffers and prevent stale data from being exposed. Just like with the Spectre mitigations, the microcode updates can be distributed as part of UEFI/BIOS updates, which would make them persistent, or can be distributed by OS vendors and then reapplied by the kernel on every reboot.

In the absence of microcode mitigations, software and OS vendors can also use certain instruction sequences to achieve the buffer overwriting same effect. These sequences are documented in Intel’s white paper and can vary for different processor families.

According to Bos, software-based mitigations will have a higher performance cost than microcode-based ones, but in both cases it will be up to OS and software vendors to actually start using the buffer overwriting instructions. This means users should also look for patches from their OS and hypervisor suppliers.

Another recommendation that VUSec makes is to disable the Simultaneous Multi-Threading (SMT), also known as Intel Hyper-Threading Technology. This doesn’t fully mitigate all attacks but prevents most of them and makes the others harder to execute. The downside is that disabling SMT can also negatively impact the performance of certain workloads. Intel has recommendations for environments that use SMT in its paper.

It’s also worth noting that OpenBSD’s developers decided to disable SMT by default in their kernel scheduler last year after a different vulnerability related to CPU buffers was disclosed. “Since many modern machines no longer provide the ability to disable hyper-threading in the BIOS setup, [we] provide a way to disable the use of additional processor threads in our scheduler,” the OpenBSD developers said at the time. “And since we suspect there are serious risks, we disable them by default.”

The Linux kernel and several Linux distributions, including Red Hat, have added the option for users to disable SMT (hyper-threading), noting that the extent to which this will negatively impact performance depends on workload type, CPU family and other configurations. The ChromeOS developers have even disabled SMT by default starting with version 74 and believe that most users should not experience a noticeable loss of responsiveness.

Apple, however, observed a more serious impact. The company published instructions for disabling hyper-threading on macOS Mojave, High Sierra and Sierra, but warned that testing conducted by the company this month “showed as much as a 40 percent reduction in performance with tests that include multithreaded workloads and public benchmarks.”

Microsoft said hyper-threading can typically be disabled from BIOS/UEFI or through firmware configuration tools and noted the company “has seen some performance impact with these mitigations, in particular when hyperthreading is disabled.”

Graphs published by Intel on its website show that performance loss from disabling hyper-threading on PCs varies between 1% and 9% depending on benchmark and workload. However, the tests were performed on a Core i9-9900K CPU, which is one of the company’s latest CPUs and has mitigations for speculative execution attacks built in.

Intel’s tests on data center workloads with hyper-threading disabled showed a more significant impact: 29% performance loss for server-side Java and 11% for general compute. Those tests were performed on an Intel Xeon Platinum 8180 CPU.

The problem is that making the architectural changes required to remove the risks introduced by speculative execution for good could mean giving up on some of the CPU performance we’re used to, but which, we learn now, came at the cost of security.

Meanwhile, the VUSec researchers argue that “spot” mitigations that address specific variants of side-channel speculative execution attacks are not a long-term solution because new attacks that bypass these mitigations will continue to be found.

“The lesson learned is that mitigating RIDL-like attacks with practical software mitigations is non-trivial and we need more fundamental mitigations to end the speculative execution attacks era,” the researchers said. “RIDL is ill-suited to practical mitigations in software and more fundamental mitigations are necessary moving forward.”