Plundervolt

On June 7, 2019, academics from the universities of Birmingham, Graz and Leuven disclosed to Intel® the Plundervolt attack, tracked by Intel® as CVE-2019-11157. Soon after, Intel® provided microcode updates to protect against this attack. There are no known attacks or breaches using Plundervolt. It was publicly disclosed on December 10th, 2019. The attack leverages the ability of a privileged user (root) to write to a certain undocumented MSR (Model-Specific Register) that controls the CPU voltage on Intel® Platforms. This can result in injecting faults into computations that can have security implications.

We examine the implications of such an attack in on-premise and public-cloud settings, and discuss the mitigations Intel® deployed following the disclosure.

So how is Plundervolt related to Software Guard Extensions and secure enclaves more generally?

Well, the thing is that secure enclaves are pretty much the only setting where Plundervolt potentially enables an attacker do something that it couldn’t do otherwise. Since Plundervolt requires root privileges, the only thing that a root attacker couldn’t already do on a host is to breach secure enclaves, that protect code and data even against a root-level attacker or insider.

It is important to note that this attack seems to require a very controlled setting in order to result in something beyond a random corruption that’s likely to cause an application to crash. However, to properly address the attack, it is essential to deploy the microcode updates provided by Intel®. Those mitigations are further discussed in the next section.

Mitigations

The vulnerability was responsibly disclosed to Intel® by the research group, and Intel® provided microcode updates that mitigate the attack. The Intel® SGX Remote Attestation capability enables clients to verify that a remote enclave is running on top of hardware with the latest microcode updates deployed. For any existing deployments, a TCB recovery is recommended to prevent data-breaches. This means re-encrypted sealed enclave secrets using keys derived for the new TCB.

Fault-injection Attacks on RSA Signatures

The key-extraction demonstrated in the Plundervolt paper uses a more general fault-injection attack on RSA signatures. RSA signatures are usually computed using a trick that is based on the Chinese Remainder Theorem (CRT), where instead of exponentiation modulo a large composite you exponentiate by its factors and use those intermediate exponentiations to compute the signature. The danger of using the CRT method was already observed by Boneh, DeMillo and Lipton more than twenty years ago in their work “On the importance of checking cryptographic protocols for faults” from 1997. A glitch, whether random or maliciously injected, in on of those exponentiations can enable computing the factors of the RSA modulus, leaking the private signing key. There is a simple countermeasure to that, implemented by state of the art cryptographic libraries and devices, which consists of verifying the computed signature before outputting it.

The mbedTLS and BoringSSL cryptographic libraries both perform an RSA signature validation intended to protect against fault-injection attacks as part of their default configuration. Such checks for RSA signatures have negligible performance implications given an RSA signature validation is way cheaper than the computation of the signature itself. A similar check could be implemented for AES-NI operations, albeit it would have a more serious effect on performance. Anjuna’s software is using modern cryptographic libraries that implement the countermeasures protecting signatures against fault-injection attacks.

Cloud and Virtualization

Real-world hypervisor configurations do not allow a virtual machine to write to MSR registers, as pointed by the research group in the paper. Practically, this means that if the user trusts the hypervisor, and the concern is mainly about a privileged attacker inside the virtual machine, then such an attacker would not be able to exercise the Plundervolt attack and SGX enclaves running within the virtual machine are secure, even without the microcode mitigations.

Conclusion

At Anjuna, we follow closely all new research related to the security of the Intel® SGX technology. We are excited to see that the best minds in the systems security space are looking at the technology, and through responsible disclosures help strengthen security and close any discovered loopholes. Intel’s microcode updates and attestation enable on one hand to address newly discovered issues, and on the other hand verify that those updates were indeed deployed.

For further inquiries about the Plundervolt attack and for additional information, welcome to reach out to us at info@anjuna.io.