Plundervolt

PlunderVolt Papers

Introduction
Modern processors are being pushed to perform faster than ever before - and with this comes increases in heat and power consumption. To manage this, many chip manufacturers allow frequency and voltage to be adjusted as and when needed. But more than that, they offer the user the opportunity to modify the frequency and voltage through priviledged software interfaces. With Plundervolt we showed that these software interfaces can be exploited to undermine the system's security. We were able to corrupt the integrity of Intel SGX on Intel Core processors by controling the voltage when executing enclave computations. This means that even Intel SGX's memory encryption/authentication technology cannot protect against Plundervolt.

Videos



Questions
Who reported this?
Pundervolt was first reported on June 7, 2019 by a group of international researchers:

Kit Murdock, David Oswald, Flavio D Garcia (The University of Birmingham)
Jo Van Bulck, Frank Piessens (imec-DistriNet, KU Leuven)
Daniel Gruss (Graz University of Technology)
Before that, Navjivan Pal looked at the potential of using undervolting for faulting (non-SGX) computations within his final year project at the University of Birmingham under supervision of David Oswald.

We have also been informed by Intel that other researchers reported a similar issue after our initial disclosure to Intel on 7 June 2019. We currently do not know who these researchers are, but there might be reports for a similar attack under a different name. Intel has confirmed that we were the first group to report this issue.

What is Intel SGX?
Intel Software Guard Extensions (SGX) is a set of security-related instruction codes that are built into modern Intel CPUs. SGX allows to shield sensitive computations inside so-called "enclaves". The contents of these enclaves are protected and cannot be accessed or modified from outside the enclave. This includes an attacker who has root privileges in the normal (untrusted) operating system.

Does this attack affect only SGX, or also other applications on Intel processors?
Plundervolt is a similar class of Undervolting attacks like CLKScrew and VoltJockey executed on SGX enclaves. This is because the undervolting interface is only accessible with root privileges in the untrusted operating system - it would not make sense to attack software with undervolting when you're already root, apart from the case of SGX (which should protect against a root attacker). We also reviewed common hypervisors and virtual machine software, and found that the guest OS cannot access the undervolting interface (which otherwise would allow an attack on the host OS).

Does an attacker need physical access to my computer for this?
No. The undervolting interface is accessible from software, so if a remote attacker can become root in the untrusted OS, she can also mount the Plundervolt attack. In any case, note that attackers with physical access would also be in the threat model of SGX (e.g. to protect against malicious cloud providers).

What should affected user do?
If you do not use SGX, you do not need to do anything. If you do use SGX: Intel has released a microcode update that - together with a BIOS update - allows disabling of the undervolting interface. The fact that undervolting is disabled will be reflected in remote attestation. More information can be found in Intel's security advisory.

Should I worry about Plundervolt if my enclave does not perform cryptographic operations?
Yes. In addition to the extraction of cryptographic keys, Plundervolt can also cause memory safety misbehaviour in certain scenarios. Specifically, we show that out-of-bounds accesses may arise when an attacker faults multiplications emitted by the compiler for array element indices or pointer arithmetic. Plundervolt can break the processor's integrity guarantees, even for securely written code. In the paper, we show that Plundervolt may affect SGX's attestation functionality, undermining the building blocks that underpin the security of Intel's SGX ecosystem.

How have Intel responded?
Intel responded quickly after we started the responsible disclosure process on 7 June 2019. Since then, Intel has discussed the issue with us and kept us informed of their timeline. Intel provides more information about TCB recovery and attestation on their website.

Is there proof-of-concept code?
Yes, check our Plundervolt Github repository.

Is there a CVE?
Yes. CVE-2019-11157.

Where can I find the paper?
Here: Plundervolt: Software-based Fault Injection Attacks against Intel SGX

Is this the same as Rowhammer?
No. RowHammer allows an attacker to flip bits in memory, but this does not work for SGX-protected memory. This is because SGX cryptographically ensures that physical memory is not changed outside the SGX environment. Plundervolt flips bits inside the CPU, before they are written to memory, and hence is not prevented by SGX's memory protection.

Is this related to the CLKScrew or VoltJockey attacks?
Yes and no. CLKScrew and VoltJockey target ARM processors and ARM Trustzone, while we attack on Intel SGX. However, Plundervolt and CLKScrew/VoltJockey are similar in that they use a privileged power/clock management feature to inject faults into a trusted execution environment. Besides, with Plundervolt we show that fault injection can achieve more than extracting cryptographic keys: we show that faults can be used to maliciously change the data flow in programs that do not use cryptography at all.

How is this related to speculative execution attacks like Spectre or Foreshadow?
Speculative execution attacks like Foreshadow or Spectre allow to read data from SGX enclave memory (i.e. attacks the confidentiality). Plundervolt achieves the complementary operation, namely changing values in SGX-protected memory (i.e. attacks the integrity).

Why is it called Plundervolt?
The dictionary definition of plunder: ˈplən-dər To steal or remove something precious from something, in a way that does not consider moral laws.

Should I now throw away my CPU or stop using SGX altogether?
No, definitely not. If you are not using SGX, no actions are required. If you are using SGX, it suffices to apply the microcode update provided by Intel to mitigate Plundervolt.