Clkscrew: Exposing the perils of security-oblivious energy management | Hacker News Reader

Clkscrew: Exposing the perils of security-oblivious energy management

blog.acolyer.org

92 pointsfanf215 comments

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.

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.

It might be a better approach to have executing code signal if a segment is a security-critical section or not. In that way a performance hit might be taken while doing work in a properly secure way but the rest of the time things could be run in a looser manor.

Taking that concept further, it might be worth it to have an 'edgy' state as well, where the results aren't super critical but merely nice to have (EG for software video decoding).

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.

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?

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.

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

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... [1] https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...

I could be wrong, but I don't think sandboxed apps on iOS can control the CPU frequency/voltage like this.

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?

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.

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

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

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?

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.

Reply on news.ycombinator.com