Introduction
Previous work such as Plundervolt has shown that software-based undervolting can induce faults into Intel SGX enclaves and break their security guarantees. However, Intel has addressed this issue with microcode updates.
Later, we discovered VoltPillager - a hardware-based undervolting method that can achieve the same (and more) as Plundervolt, bypassing all currently available countermeasures for SGX. However, this attack requires physical access to the server - opening the box and adding additional hardware.
Both of these previous attacks use the SVID interface to change the CPU voltage. With PMFault, we revived the voltage control of certain server CPUs through the PMBus - another voltage control interface based on the I2C protocol and usually implemented by a server Voltage Regulator Module (VRM).
Due to flaws in the design of Supermicro 11th generation motherboards, we can gain access to the PMBus through multiple paths: 1) via an I2C connection from the OS running on CPU, or 2) vulnerabilities found in another microcontroller called the Baseboard Management Controller (BMC), which often exists on server motherboards. With the revived undervolting attack, we demonstrate that fault injection into SGX enclaves can be carried out remotely via software again . Moreover, we discovered an overvolting attack that can permanently brick the server CPU.
Our results may require a rethink of the security analysis process of server platforms: The security is not only down to ensuring the security of the software running on it, but the overall design of the hardware and embedded systems on the motherboard should also go through a thorough security review. Securing such a system needs the collaborative effort of both software developers and hardware engineers.
The academic paper will be presented at CHES 2023.
Demo video of the overvolting attack
FAQ
What is Intel SGX?
Intel Software Guard Extensions (SGX) is a set of security-related instructions 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. Intel SGX is also often assumed to protect the trusted code from attackers who have physical control of the platform, such as an untrusted cloud provider.
Does an attacker need physical access to my server for this?
No physical access is required for Supermicro 11th gen motherboards - this attack can be carried out remotely via SSH.
What is the threat model?
For undervolting attacks against SGX, we assume that an attacker (including a malicious insider) has full software access to the system but no (or limited) physical access. More precisely, the attacker has root access to the OS and software access to the BMC via the KCS interface or Ethernet.
For the overvolting attack, we similarly assume an attacker who has root privilege on the host CPU. The attacker could be a user of the bare metal instance provided by cloud providers. Clearly, the root user should have full control of the system but should not cause any physical damage to the system.
More details on the threat model can also be found in our paper.
Which server are affected?
In principle, any server that has the PMBus exposed through an I2C connection to the CPU or BMC can be affected by PMFault. We performed our case study on a 11th generation Supermicro motherboard (X11SSL-CF). We also detected that a VRM exists on the PMBus on X11SPG-TF and X11SSE-F Supermicro motherboards and hence believe that these motherboards are equally affected. To the best of our knoweledge, Supermicro 12th gen server motherbards already have mitigations implemented to prevent our attacks.
Is there a tool for checking the PMBus connection?
We provide the PMBusDetect tool for scanning the I2C bus for a VRM. However, due to a lack of access to server hardware, it currently only supports detecting certain VRM types. We hence decide to open-source this tool and hope that the community can contribute for a better view of the PMBus landscape.
Do the patches for CVE-2019-11157 (Plundervolt) protect against PMFault?
No, these patches simply disable the software undervolting interface which is used for sending messages through the SVID interface. PMFault uses another interface, the PMBus.
I’m not using SGX - do I need to be worried?
Yes, it could be possible to use PMfault to overvolt the CPU and permanently brick it.
Should I stop using and throw away my CPU now?
No!
Is there a CVE, and how did Supermicro respond?
We have responsibly disclosed our findings to Intel and Supermicro in April 2022. We discussed the details of our methods in several calls with Supermicro, and they acknowledge the existence of the issue and are looking into deploying fixes for their 11th generation products like the X11SSL-CF. Supermicro highlighted that the attacks do not replicate on their 12th generation, which e.g. include secure boot and update for the BMC and filtering on PMBus commands. Both of these features break the attack chains described in the paper. Intel considered the issue in the context of their own server motherboards and did not find them vulnerable. Intel did not comment on the impact on SGX.
Supermicro has published a Security Advisory for this issue.
CVE-2022-43309 has been reserved for PMFault.
Where can I find the code and more information?
All sources and PoC code can be found in our Github repo.
Can I use the logo?
Yes. The logo is free to use, rights waived via CC0.
Is there a citation to the paper yet?
We will update the citation as soon as the paper is published.
@article{Chen_Oswald_2023,
title={PMFault: Faulting and Bricking Server CPUs through Management Interfaces: Or: A Modern Example of Halt and Catch Fire},
author={Chen, Zitai and Oswald, David},
year={2023},
month={Mar.},
journal={IACR Transactions on Cryptographic Hardware and Embedded Systems},
volume={2023},
number={2},
pages={1-23},
url={https://tches.iacr.org/index.php/TCHES/article/view/10275},
DOI={10.46586/tches.v2023.i2.1-23}
}
Acknowledgements
This research is partially funded by the Engineering and Physical Sciences Research Council (EPSRC) under grants EP/R012598/1, EP/R008000/1, and EP/V000454/1. The results feed into DsbDtech. We would also like to thank Supermicro for providing a X12DPi-NT6 server for further investigation of the issue.