
Clkscrew: Exposing the perils of security-oblivious energy management - fanf2
https://blog.acolyer.org/2017/09/21/clkscrew-exposing-the-perils-of-security-oblivious-energy-management/
======
nickpsecurity
This is an amazing piece of work. They started with a good concept then hit it
from all angles. I posted about risk areas such as this on Schneier's blog
long ago. When debating with Joanna of Qubes, one of the reasons she said she
chose Xen over the security-focused microkernels I mentioned was she wanted
the power management it already had. When people told me how that worked, I
told the readers that the implementation was way too complicated to trust in a
secure system. Management features should be on a microcontroller sitting
outside the CPU running verifiable algorithms. If on CPU, in an truly-isolated
partition at the least. Also, use proper isolation on system in general to
limit shared resources due to covert & side channels. Typical of separation
kernels.

So, this attack happens since isolation is broken in numerous ways plus stuff
is on-CPU. It was preventable but it would cost extra. The market prefers to
make extra money per unit then clean up after a disaster. Everything is
running right on schedule. Note that the needs of mobile might justify keeping
things in the SoC but the isolation failures weren't necessary. The embedded
and mobile segments have had for some time SoC support for coprocessors,
accelerators for specific functions, and separation kernels. I thinking
they're avoiding those to squeeze out extra profit.

~~~
otakucode
Yeah, this is just 'wow' level work. And it's going to be a NIGHTMARE to fix.
I don't think most people realize how much of a ballet it is that chips on
devices like phones are doing on a nanosecond-to-nanosecond basis. The thermal
and energy management is utter voodoo. They're allocating work to different
parts of the chip calculating the time it will take for the last hotspot to
drop close enough to thermal equilibrium to be used again without straight up
destroying the circuits, dancing activity all around the chip just to avoid
frying it. To them layer on top of that 'well you have to do it in a way that
emits not a single bit of useful information in any form, thermal, radio,
energy, etc'... someone somewhere who is very smart is having a very, very bad
day.

~~~
wmf
This particular attack isn't that bad. It relies on putting the VRM into
"illegal" configurations (overclocking/undervolting) thus it can be fixed by
preventing such configurations in hardware.

------
ak217
This is really cool, but do sandboxed Android apps really have access to set
CPU frequency/voltage to invalid combinations? Or is this only useful as a way
to break into the secure enclave after getting root privilege escalation
through other means?

~~~
wmf
You definitely have to be root to do this. In the future there might be a
dedicated core (PCU) to control frequency/voltage so even root on the main
cores may not be able to do it.

------
Whitespace
Absolutely phenomenal hack. This is state-actor-level stuff.

I'm no expert, but iPhone might also use essentially the same ARM
TrustZone/SecurCore tech as per [0].

If that's the case I wouldn't be surprised if we saw the same group targeting
iPhones in a couple of months.

[0]
[https://en.wikipedia.org/wiki/Apple_A7](https://en.wikipedia.org/wiki/Apple_A7)

~~~
shaded-enmity
The prerequisite for mounting this attack is kernel code execution already
[0]:

> We show that a malicious kernel driver ...

As per [1] the Power management unit is shared between the Application
Processor (AP) and the Secure Enclave Processor (SEP) so this attack might
work against iPhones as well.

[0]
[https://www.usenix.org/conference/usenixsecurity17/technical...](https://www.usenix.org/conference/usenixsecurity17/technical-
sessions/presentation/tang) [1]
[https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-
De...](https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-
The-Secure-Enclave-Processor.pdf)

------
kbenson
So, given that this is a new _class_ of attacks, and they mention the Nexus 6
as an example but that it works on commodity ARM chips in general, do we know
whether this _current_ exploit implementation refereced could be adapted to
Apple's ARM chips, or whether they have a different setup that prevents this
implementation?

~~~
wmf
Apple's secure enclave is a separate core. Also, it's not clear that direct
control over frequency and voltage is possible even on a jailbroken iPhone.

~~~
Cyph0n
If the iOS kernel does DVFS in software, then this attack will likely still
work.

------
als0
Note that this doesn't seem to be an issue with TrustZone itself, but on the
operating limits of the regulators for some vendors.

------
toystory9
This hack shouldn't work against iPhones, right? Even with full physical
access to the phone, power analysis with physical tools was unable to extract
keys from the secure enclave. Moreover, since the key is physically burnt into
the silicon, shouldn't that mean it shouldn't be extractable via power
analysis anyway?

~~~
jnwatson
This isn't a power analysis attack. This is a fault injection attack. If
cryptography is being done in software and the trusted core voltage and/or
frequency is controllable by the attacker, the iPhone could be vulnerable.

