19 comments

[ 45.9 ms ] story [ 925 ms ] thread
> How a little bit of undervolting can cause a lot of problems

> 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

The page itself even mentions that it's an old exploit, it seems:

> 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.

The title should be something like "Plundervolt (2019)".
Title is fixed now, but it gave me a bit of a shock when I read this today.
After many side channel attacks on SGX Intel revealing fundamental design flaws, SGX is absent in recent Intel processors.

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.

I always assumed that SGX's use by Signal is just "cute" and "nice to have" and "defense in depth", not anything on which the security of my communication actually depends. Am I mistaken?
Would you think same for Apple Secure Enclave or ARM TrustZone?
How does SGX work on non-Intel Android?
It doesn't. Signal uses it on the server side.
Can you use Plundervolt into tricking the CPU into self-reporting that undervolting is disabled?
I'm pretty sure the fact that with root permissions you can leak data out of an SGX enclave is news to a few people, like the CCC and anyone who's staked their business to the security promises provided by TEEs. Voltage glitching in person is different from doing it in a repeatable way in software from halfway around the globe. When you've got a Metasploit module for overflowing buffers in trusted enclaves by executing code that drops processor voltage, that's an interesting timeline to live in.
Would it be possible to EYA for AUD?
> I thought this attack vector was pretty well known

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.

(comment deleted)
Is the recent deprecation of SGX on Intel's consumer processors related to this? I can imagine that it would make certain use cases like DRM unusable, as people might be able to extract encryption keys.
I recall this debacle; the patch to address this (aka disable undervolting) caused a huge furore at forum.notebookreview.com (which has since closed; what a pity), which was full of enthusiasts undervolting and overclocking their notebook CPUs and GPUs. It is worth noting that CPU undervolting gives a roughly 15±5% performance boost to all notebooks with modern Intel CPUs (Haswell and later), while keeping power draw the same—one might understand why enthusiasts were irritated by the patch.

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...