Computer security researchers involved in the discovery of the Meltdown and Spectre vulnerabilities affecting many modern processors have developed a related attack technique called Load Value Injection (LVI).
The attack relies on microarchitectural data leakage to inject and execute malicious code in a way that breaks the confidentiality of modern Intel systems.
Chipzilla's processors, already weighed down by defenses deployed against side-channel attacks over the past two years, could get slower still if they try to thwart this latest vulnerability: prototype compiler changes, for full mitigation, have produced performance reductions ranging from 2x to 19x.
That's because LVI protection involves compiler and assembler updates that insert extra x86 instructions (
lfence) and replace problematic instructions (such as
ret) with functionally equivalent but more verbose instruction sequences.
In a paper scheduled to be published today, March 10, in a coordinated disclosure announcement with Intel, boffins from KU Leuven, Worcester Polytechnic Institute, Graz University of Technology, University of Michigan, and University of Adelaide, describe LVI as a reverse-Meltdown attack. Instead of leaking data from memory, it injects transient load values during a faulting or assisted load operation to perform some malicious action.
Using Spectre-style code gadgets – pre-existing code patterns in memory that can be manipulated to perform operations for the attacker – LVI can expose secrets and compromise Intel's SGX secure enclave technology. SGX, in fact, makes the attack easier because the tech's design allows attackers to create page faults for enclave memory loads by altering untrusted page tables.
Jo Van Bulck (KU Leuven) discovered and reported the issue on April 4, 2019, and worked with Daniel Moghimi, Michael Schwarz, Moritz Lipp, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss, and Frank Piessens to develop and refine the technique.
In February 2020, shortly before planned disclosure, Bitdefender security researchers Andrei Lutas and Dan Lutas independently came up with a proof-of-concept for one of several LVI variants called LVI-LFB, which applies to cross-process hyperthreading scenarios. Other LVI variants include LVI-NULL, LVI-L1D, LVI-FPU, and LVI-SB.
LVI, designated CVE-2020-0551 and Intel-SA-00334, is not a remote code execution threat; it's dangerous mainly in multi-tenant environments such as enterprise workstations or servers in data centers. Intel considers it a medium (5.6) severity vulnerability.
AMD, boffins clash over chip data-leak claims: Side-channel holes revealed in decade of processorsREAD MORE
The threat scenario involves a local adversary trying to obtain secrets (like passwords or encryption keys) from an operating system kernel, an OS process, or an SGX enclave. For SGX, root OS privileges are assumed – SGX was designed to protect against root-level attacks. With such secrets, more extensive compromise becomes possible.
It turns out that Meltdown, a technique for pulling data from a computer's memory, can be turned around to put data back in, thereby poisoning data stored in memory during brief, speculative operations. Though the data gets thrown away after these short-lived tasks, it can still cause trouble.
While LVI utilizes code gadgets cherry-picked from memory, just like Spectre-style branch prediction hijacking, it differs in that it's more broadly applicable. It doesn't require mistraining a branch predictor (so it works on CPUs without prediction components and on systems that have current microcode and compiler defenses) and it hijacks control-flow after the target machine tries to fetch a branch-target from memory instead of beforehand.
"Our key contribution is to recognize that, under certain adversarial conditions, unintended microarchitectural leakage can also be inverted to inject incorrect data into the victim’s transient execution," the paper explains. "Being essentially a 'reverse Meltdown'-type attack, LVI abuses that a faulting or assisted load instruction executed within a victim domain does not always yield the expected result, but may instead transiently forward dummy values or (attacker-controlled) data from various microarchitectural buffers."
A video posted to YouTube by one of the researchers, Daniel Gruss (Graz University of Technology), offers a demonstration:
In a technical analysis Intel intends to publish on Tuesday alongside a blog post, the chipmaker explains that, in some processors, faulting or assisting load instructions may receive speculative data from a processor buffer.
"If an adversary can cause a specified victim load to fault, assist, or abort, the adversary may be able to select the data to have forwarded to dependent operations by the faulting/assisting/aborting load," Intel's technical paper explains.
"For certain code sequences, those dependent operations may create a covert channel with data of interest to the adversary. The adversary may then be able to infer the data’s value through analyzing the covert channel. This transient execution attack is called Load Value Injection (LVI) and is an example of a cross-domain transient execution attack."
Intel insists this isn't really a matter of concern in non-SGX environments. In a statement emailed to The Register, a spokesperson said: "Due to the numerous complex requirements that must be satisfied to successfully carry out, Intel does not believe LVI is a practical method in real world environments where the OS and VMM are trusted."
The researchers in their paper make clear the chip maker isn't quite so blasé about the risks where SGX comes into play: "Intel considers LVI particularly severe for SGX…"
"We agree with Intel's assessment that LVI is less practical and more difficult to mount in a non-SGX setting where the operating system and VMM are trusted," said Van Bulck in an email to The Register. "But LVI has definitely real-world impact for SGX, which is why we engaged in an extended responsible disclosure embargo."
Bogdan Botezatu, director of threat research for Bitdefender, didn't sound particularly worried in an email to The Register.
"Just like Meltdown, Spectre, the MSD attacks and the SWAPGS attack discovered in the past, the LVI-LFB attack once again defeats security boundaries enforced at the silicone level," Botezatu said.
"The attack itself is moderately complex to execute and we're not expecting it to be widely spread against consumers, it is a very good avenue into multi-tenant environments such as public cloud infrastructures, endpoints in the enterprise or other workloads that are shared amongst clients. Because this means of exploiting the CPU leaves no forensic evidence behind, it could be used in high-profile state- or corporate-espionage campaigns, for instance."
There's no microcode update planned, as there was with Meltdown and Spectre. But Chipzilla is releasing updates to its SGX Platform Software and SDK. It has also worked with partners like Microsoft to make compiler and assembler options available to guard against LVI.
Defending against LVI, the researchers' paper explains, "requires serializing the processor pipeline with
lfence instructions after possibly every memory load. Additionally and even worse, due to implicit loads, certain instructions have to be blacklisted, including the ubiquitous x86
And that's what Intel suggests, ensuring that a
lfence instruction gets executed after each instruction that performs a load operation. It's making a patched GNU assembler available with
lfence insertion baked in; and it's helping develop an extension for the clang compiler (part of LLVM) that will do the same. Also, Microsoft is planning to modify its Visual C/C++ compiler to add the
lfence instruction if needed.
The compiler changes include special support for modifying instruction sequences that combine a load operation with dependent memory access or branch operation. The
ret instruction, for example will get replaced with:
POP <scratch register> LFENCE # Forces the pop to retire JMP <scratch register>
Due to lack of information about registers, assemblers produce slight different output:
NOT QWORD PTR [rsp] NOT QWORD PTR [rsp] LFENCE RET
Depending upon the applications and optimizations involved, the researchers report performance overhead increases ranging from 2x to 19x when full mitigation is implemented.
Asked whether it agreed with the researchers' estimate, Intel did not respond. Intel's technical paper avoids specific figures, saying only that the performance impact of full mitigation in an SGX environment "will vary depending on workload but may be significant in some cases." The paper goes on to suggest that if the impact is too much and their threat model allows it, software vendors may want to deploy only partial mitigations.
Van Bulck said he and his fellow boffins have only demonstrated LVI on Intel processors. In principle, he said, any CPU affected by Meltdown would also be affected by LVI, but he emphasized that Intel chips are particularly vulnerable for two reasons.
One, he said, is that Meltdown-type leakages, including Foreshadow, ZombieLoad, Fallout, and RIDL, mainly affected Intel. The other is that LVI requires inducing faults in a victim program and this is trivial with SGX but more difficult with other Trusted Execution Environments like Arm TrustZone.
"We believe that none of the ingredients for LVI are exclusive to Intel processors," Van Bulck explained. "However, LVI turns out to be most practically exploitable on Intel processors because of the combination of the facts that we have seen more Meltdown-type leakage sources there that can potentially be inverted, plus certain design decisions that are specific to the Intel SGX architecture (i.e. untrusted page tables)."
That said, Arm and IBM have been notified of the findings, as has Microsoft, which is said to be investigating whether LVI has implications for the Windows kernel.
"We consider non-SGX LVI attacks of mainly academic interest and we agree with Intel's current assessment to not deploy extra mitigations for non-SGX environments, but we encourage future research to further investigate LVI in non-SGX environments," said Van Bulck. ®