SPOILER alert, literally: Intel CPUs afflicted with simple data-spewing spec-exec vulnerability

Updated Further demonstrating the computational risks of looking into the future, boffins have found another way to abuse speculative execution in Intel CPUs to steal secrets and other data from running applications.

This security shortcoming can be potentially exploited by malicious JavaScript within a web browser tab, or malware running on a system, or rogue logged-in users, to extract passwords, keys, and other data from memory. An attacker therefore requires some kind of foothold in your machine in order to pull this off. The vulnerability, it appears, cannot be easily fixed or mitigated without significant redesign work at the silicon level.

Speculative execution, the practice of allowing processors to perform future work that may or may not be needed while they await the completion of other computations, is what enabled the Spectre vulnerabilities revealed early last year.

In a research paper distributed this month through pre-print service ArXiv, "SPOILER: Speculative Load Hazards Boost Rowhammer and Cache Attacks," computer scientists at Worcester Polytechnic Institute in the US, and the University of Lübeck in Germany, describe a new way to abuse the performance boost.

The researchers – Saad Islam, Ahmad Moghimi, Ida Bruhns, Moritz Krebbel, Berk Gulmezoglu, Thomas Eisenbarth and Berk Sunar – have found that "a weakness in the address speculation of Intel’s proprietary implementation of the memory subsystem" reveals memory layout data, making other attacks like Rowhammer much easier to carry out.

The researchers also examined Arm and AMD processor cores, but found they did not exhibit similar behavior.

"We have discovered a novel microarchitectural leakage which reveals critical information about physical page mappings to user space processes," the researchers explain.

"The leakage can be exploited by a limited set of instructions, which is visible in all Intel generations starting from the 1st generation of Intel Core processors, independent of the OS and also works from within virtual machines and sandboxed environments."

The issue is separate from the Spectre vulnerabilities, and is not addressed by existing mitigations. It can be exploited from user space without elevated privileges.

SPOILER doesn't stand for anything. In an email to The Register, Daniel (Ahmad) Moghimi explained: "We picked a named that starts with 'Sp', since it's an issue due to speculative execution and it kinda spoils existing security assumptions on modern CPUs."

SPOILER describes a technique for discerning the relationship between virtual and physical memory by measuring the timing of speculative load and store operations, and looking for discrepancies that reveal memory layout.

"The root cause of the issue is that the memory operations execute speculatively and the processor resolves the dependency when the full physical address bits are available," said Moghimi. "Physical address bits are security sensitive information and if they are available to user space, it elevates the user to perform other micro architectural attacks."

Memory madness

Modern processors manage reading and writing to RAM using a memory order buffer to keep track of operations. The buffer is used to perform store instructions – copying data from a CPU register to main memory – in the order they are laid out in executable code, and perform load operations – copying data from main memory to a register – out-of-order, speculatively. It allows the processor to run ahead and speculatively fetch information from RAM into the registers, provided there are no dependency problems, such as a load relying on an earlier store that hasn't yet completed.

Speculating about a load operation may result in false dependencies if physical address information isn't available. Intel's chips perform memory disambiguation to prevent computation on invalid data, arising from incorrect speculation.

They just don't do it all that well. "The root cause for SPOILER is a weakness in the address speculation of Intel’s proprietary implementation of the memory subsystem which directly leaks timing behavior due to physical address conflicts," the paper explains.

"Our algorithm, fills up the store buffer within the processors with addresses that have the same offset but they are in different virtual pages," said Moghimi. "Then, we issue a memory load that has the same offset similarly but from a different memory page and measure the time of the load. By iterating over a good number of virtual pages, the timing reveals information about the dependency resolution failures in multiple stages."

SPOILER, the researchers say, will make existing Rowhammer and cache attacks easier, and make JavaScript-enabled attacks more feasible – instead of taking weeks, Rowhammer could take just seconds. Moghimi said the paper describes a JavaScript-based cache prime+probe technique that can be triggered with a click to leak private data and cryptographic keys not protected from cache timing attacks.

Mitigations may prove hard to come by. "There is no software mitigation that can completely erase this problem," the researchers say. Chip architecture fixes may work, they add, but at the cost of performance.

Intel is said to have been informed of the findings on December 1, 2018. The chip maker did not immediately respond to a request for comment. The paper's release comes after the 90 day grace period that's common in the security community for responsible disclosure.

Moghimi doubts Intel has a viable response. "My personal opinion is that when it comes to the memory subsystem, it's very hard to make any changes and it's not something you can patch easily with a microcode without losing tremendous performance," he said.

"So I don't think we will see a patch for this type of attack in the next five years and that could be a reason why they haven't issued a CVE." ®

Updated to add

An Intel spokesperson told us after publication that it hopes applications can be built in future to defend against SPOILER attacks, or hardware protections can be deployed: