New speculative execution bug leaks data from Intel chips’ internal buffers

First disclosed in January 2018, the Meltdown and Spectre attacks have opened the floodgates, leading to extensive research into the speculative execution hardware found in modern processors, and a number of additional attacks have been published in the months since.

Today sees the publication of a range of closely related flaws named variously RIDL, Fallout, ZombieLoad, or Microarchitectural Data Sampling. The many names are a consequence of the several groups that discovered the different flaws. From the computer science department of Vrije Universiteit Amsterdam and Helmholtz Center for Information Security, we have "Rogue In-Flight Data Load." From a team spanning Graz University of Technology, the University of Michigan, Worcester Polytechnic Institute, and KU Leuven, we have "Fallout." From Graz University of Technology, Worcester Polytechnic Institute, and KU Leuven, we have "ZombieLoad," and from Graz University of Technology, we have "Store-to-Leak Forwarding."

Intel is using the name "Microarchitectural Data Sampling" (MDS), and that's the name that arguably gives the most insight into the problem. The issues were independently discovered by both Intel and the various other groups, with the first notification to the chip company occurring in June last year.

Read 12 remaining paragraphs | Comments

Google: Software is never going to be able to fix Spectre-type bugs

Google: Software is never going to be able to fix Spectre-type bugs

Enlarge (credit: Aurich Lawson / Getty Images)

Researchers from Google investigating the scope and impact of the Spectre attack have published a paper asserting that Spectre-like vulnerabilities are likely to be a continued feature of processors and, further, that software-based techniques for protecting against them will both impose a high performance cost. In any case, the researchers continue, the software will be inadequate—some Spectre flaws don't appear to have any effective software-based defense. As such, Spectre is going to be a continued feature of the computing landscape, with no straightforward resolution.

The discovery and development of the Meltdown and Spectre attacks was undoubtedly the big security story of 2018. First revealed last January, new variants and related discoveries were made throughout the rest of the year. Both attacks rely on discrepancies between the theoretical architectural behavior of a processor—the documented behavior that programmers depend on and write their programs against—and the real behavior of implementations.

Specifically, modern processors all perform speculative execution; they make assumptions about, for example, a value being read from memory or whether an if condition is true or false, and they allow their execution to run ahead based on these assumptions. If the assumptions are correct, the speculated results are kept; if it isn't, the speculated results are discarded and the processor redoes the calculation. Speculative execution is not an architectural feature of the processor; it's a feature of implementations, and so it's supposed to be entirely invisible to running programs. When the processor discards the bad speculation, it should be as if the speculation never even happened.

Read 10 remaining paragraphs | Comments

Spectre, Meltdown researchers unveil 7 more speculative execution attacks

Spectre, Meltdown researchers unveil 7 more speculative execution attacks

Enlarge (credit: Aurich Lawson / Getty Images)

Back at the start of the year, a set of attacks that leveraged the speculative execution capabilities of modern high-performance processors was revealed. The attacks were named Meltdown and Spectre. Since then, numerous variants of these attacks have been devised. In tandem, a range of mitigation techniques has been created to enable at-risk software, operating systems, and hypervisor platforms to protect against these attacks.

A research team—including many of the original researchers behind Meltdown, Spectre, and the related Foreshadow and BranchScope attacks—has published a new paper disclosing yet more attacks in the Spectre and Meltdown families. The result? Seven new possible attacks. Some are mitigated by known mitigation techniques, but others are not. That means further work is required to safeguard vulnerable systems.

The previous investigations into these attacks has been a little ad hoc in nature; examining particular features of interest to provide, for example, a Spectre attack that can be performed remotely over a network, or Meltdown-esque attack to break into SGX enclaves. The new research is more systematic, looking at the underlying mechanisms behind both Meltdown and Spectre and running through all the different ways the speculative execution can be misdirected.

Read 14 remaining paragraphs | Comments

New Spectre attack enables secrets to be leaked over a network

Enlarge (credit: Pete)

When the Spectre and Meltdown attacks were disclosed earlier this year, the initial exploits required an attacker to be able to run code of their choosing on a victim system. This made browsers vulnerable, as suitably crafted JavaScript could be used to perform Spectre attacks. Cloud hosts were susceptible, too. But outside these situations, the impact seemed relatively limited.

That impact is now a little larger. Researchers from Graz University of Technology, including one of the original Meltdown discoverers, Daniel Gruss, have described NetSpectre: a fully remote attack based on Spectre. With NetSpectre, an attacker can remotely read the memory of a victim system without running any code on that system.

All the variants of the Spectre attacks follow a common set of principles. Each processor has an architectural behavior (the documented behavior that describes how the instructions work and that programmers depend on to write their programs) and a microarchitectural behavior (the way an actual implementation of the architecture behaves). These can diverge in subtle ways. For example, architecturally, a program that loads a value from a particular address in memory will wait until the address is known before trying to perform the load. Microarchitecturally, however, the processor might try to speculatively guess at the address so that it can start loading the value from memory (which is slow) even before it's absolutely certain of which address it should use.

Read 11 remaining paragraphs | Comments