Plundervolt (2019)
plundervolt.com
plundervolt.com
My previous Dell notebook was issued firmware updates[0] for this CVE: CVE-2019-11157. However, the 'bug' was never properly patched, and resetting the firmware to factory defaults after an upgrade could restore undervolting.
In my current notebook (also a Dell: Precision 7560), undervolting is disabled to begin with, but it may be restored by modifying UEFI variables[1].
[0]: https://www.dell.com/support/home/en-sg/drivers/driversdetai...
[1]: https://brendangreenley.com/undervolting-2020-dell-laptops-l...
Previous discussion: https://news.ycombinator.com/item?id=21759683
> 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.
I thought this attack vector was pretty well known and thoroughly-explored on many systems by now, but it's always good to get the word out farther and wider
> Plundervolt was first reported on June 7, 2019 by a group of international researchers:
And that it appears to be fixed?
> 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.
Centralized services like Signal still pinky swear they will not use any of these exploits and break all the metadata promises they built on SGX. Even if the US government asks them nicely.
Any security built on SGX is security theater.
More reasons to avoid Xeon :-P
https://community.intel.com/t5/Blogs/Products-and-Solutions/...
Yes, fault attacks are well known, but this paper is about software-based fault attacks.
And as discussed in section I.A), the various integrity check mechanisms of SGX were believed to be able to protect against this.