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.
Plundervolt was first reported on June 7, 2019 by a group of international researchers:
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 were also informed by Intel that other researchers reported a similar issue after our initial disclosure to Intel on 7 June 2019. The two other research teams who independently reported this issue are VoltJockey and V0LTpwn. Intel has confirmed that we were the first group to report this issue.
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.
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).
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).
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.
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.
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.
Yes, check our Plundervolt Github repository.
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.
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.
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).
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.
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.
Yes. Email us at firstname.lastname@example.org.
This research is partially funded by the Research Fund KU Leuven, and by the Agency for Innovation and Entrepreneur- ship (Flanders). Jo Van Bulck is supported by a grant of the Research Foundation – Flanders (FWO). This research is partially funded by the Engineering and Physical Sci- ences Research Council (EPSRC) under grants EP/R012598/1, EP/R008000/1, and by the European Union’s Horizon 2020 research and innovation programme under grant agreements No. 779391 (FutureTPM) and No. 681402 (SOPHIA).