ARM TrustZone Hacked By Abusing Power Management (acolyer.org) 60
"This is brilliant and terrifying in equal measure," writes the Morning Paper. Long-time Slashdot reader phantomfive writes: Many CPUs these days have DVFS (Dynamic Voltage and Frequency Scaling), which allows the CPU's clockspeed and voltage to vary dynamically depending on whether the CPU is idling or not. By turning the voltage up and down with one thread, researchers were able to flip bits in another thread. By flipping bits when the second thread was verifying the TrustZone key, the researchers were granted permission. If number 'A' is a product of two large prime numbers, you can flip a few bits in 'A' to get a number that is a product of many smaller numbers, and more easily factorable.
"As the first work to show the security ramifications of energy management mechanisms," the researchers reported at Usenix, "we urge the community to re-examine these security-oblivious designs."
"As the first work to show the security ramifications of energy management mechanisms," the researchers reported at Usenix, "we urge the community to re-examine these security-oblivious designs."
Every time (Score:5, Funny)
Every time I hear about security, viruses and hacks, it's done via "opcodes", "registers" and "bits". Isn't it time we design more secure processors without these flaws?
Re: (Score:1)
https://en.wikipedia.org/wiki/... [wikipedia.org]
you make no sense.
Sefcurify (Score:3)
It would all be more secure if there were a backdoor engineered into the design so the government could have unfettered access to our data. You know, to make sure it's secure.
Re: (Score:3)
Normally at this level for the hack we start to cross the line from the digital to the analog. While most of us coders just worry about 0 and 1, on the processor we are looking at a values between a threshold, where wires are so close that a power change could cause a little static arch that in theory can change a bit.
However these hacks normally need to be times perfectly and with intimate knowledge on what is going on at that time. Such a hack would most likely cause a program to fail, or some bad data t
Re:Every time (Score:5, Funny)
Better yet, don't name your product with a name that can later become ironic, like "TrustZone." Try naming your product "ShitStorm" or "ClusterFuck" instead. That way, when it gets hacked or turns out to be buggy as hell, you can say "What did you expect? We told you so upfront."
Re: (Score:2)
Other large semiconductor companies seem to be able to implement a secure enclave structure with dynamic voltage wobbling and managed to take fault injection seriously and they don't have these problems. It's heavy lifting to do a proper job, but in the case of RSA, it really isn't. Just sprinkle in some TMR and integrity testing with maybe a rail monitor and you will be good. I wonder why that isn't a part of TrustZone as standard. It should be.
You are right. Management can't see security problems when you
Re: (Score:2)
Actually, TrustZone is an excellent architecture.
TrustZone is a terrible architecture. It started as a hash-for-secure-boot and then had more and more crap bolted onto it without rhyme or reason as the marketing folks sold it as all things to all people, with most of what was bolted on only partly finished or debugged, if that. The OPs suggestion that it be rebranded as ClusterFuck isn't too far off the target, because that's what it's turned into.
Re: (Score:2)
Better yet, don't name your product with a name that can later become ironic, like "TrustZone." Try naming your product "ShitStorm" or "ClusterFuck" instead.
"With a name like that, you know it HAS to be good!" Like that old Saturday Night Live skit where they come up with bad names for the jelly. "Fruckers! You know it must be good!" Followed by "Monkey Pus!", "Painful Rectal Itch!", and "Death Camp! Look for the barbed wire on the label!" Then "10,000 Nuns and Orphans! What's wrong with that? They were eaten by rats!"
Re: (Score:2)
I think if we could just have pink unicorns, we could ask their magical advice on how to design new processors.
Re: (Score:1)
No, this is a hardware design flaw. It really has nothing to do with security other than it causing a security issue as a byproduct. Really there is no reason raising and lowering the voltage should flip bits at all other than someone made a big boo boo in the design.
Re: (Score:3)
Re:Would the Rust programming language help? (Score:5, Informative)
Not in this case. Rust (and similar programming approaches) prevent accidental interference between threads (of the same application) at the code execution layer - i.e. they prevent bugs due to programming errors. This attack is happening at the hardware level - the threads in question could be completely different applications and could be written in any language.
Re: (Score:2)
Could it be stopped by making appropriate amendments to the Code of Conduct?
Re: (Score:2)
No, Rust isn't a magical device that makes all your computers secure.
It does help enforce better coding practices to make your code more secure.
However on some level the point of the programming language is to interact with the system hardware.
a Mutable data type will prevent threads from changing the data. However it doesn't stop the CPU from changing the data in the value. Because something needs to clear the memory when the variable is no longer needed (such as leaving the nest or program end)
Easy fix (Score:4, Insightful)
Re: (Score:1)
RTFM indeed, it isn't manipulated by the order of the executed instructions but by telling the dvfs system to change the voltage and frequency. So limiting access to the DVFS should mitigate the issue enough such that they'll already have root access on the system before they can mount the attack.
Re: Easy fix (Score:2)
Re: (Score:2)
Non OS code doesn't need that capability for non OS code to actually perform those actions via proxy.
Re: (Score:2)
And then somebody hacks the OS and can compromise the Trust Zone anyways. No, what we need to do is secure the OS, because this is just one more case where anybody that owns the OS owns everything.
Re: (Score:2)
Problem not solved, because breaking TrustZone means breaking the machine BENEATH the OS level.
You're kidding right? (Score:3, Interesting)
TFA tries to make the argument that this physical hack can be done remotely despite the highly controlled conditions by relying on the power and energy management utilities...
Now i've got news as an embedded developer, that sh*t isn't accurate for anything this sensitive.
Targeted (Score:2)
It would probably work for a *very* targeted attack. A specific rev of a specific device running a specific OS.
Useful for spooks, not much for anyone else. There were a bunch of these kinds of hacks in the NSA leaks - a MITM attack given a specific version of Apache, OpenSSL, and a specific version of a particular web browser.
Re: Targeted (Score:2)
The voltage variations in question are driven by the random defects in the silicon and in the fabrication process, not so much the CPU design or the OS (or even firmware) running on the chip.
Entrope is an idiot (Score:1)
The voltage variations in question are driven by the random defects in the silicon and in the fabrication process, not so much the CPU design or the OS (or even firmware) running on the chip.
RTFM, idiot:
Thus any frequency or voltage change initiated by untrusted code inadvertently affects the trusted code execution.
Re: (Score:1)
But it's the same kind of vulnerability where you take advantage of a race condition and multithreading. In software, you set up some handlers to catch the segmentation faults, and whatever. But just keep trying again and again until you get lucky.
Yes its Targeted (Score:3)
The claim that you can not manipulate the keys was made and clearly thats not the case... the team at Columbia University : Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo deserve credit for showing that was not always the case...
I wonder how many side attacks the PLA have...
john.jones.name
Re:You're kidding right? (Score:5, Interesting)
The issue in both cases is either:
a) The device can be set to operate under conditions that are known to cause it to be unreliable (be out of spec)
b) The device fails to operate reliably when operated within spec
If it is (a) then perhaps the manufacturer should test devices more thoroughly - and then blow fuses to limit operation within spec. If it is (b) the manufacturer should test the devices more thoroughly.
You may know that (eg) Intel sell processors "locked" to prevent over clocking. This prevents (a). It obviously fails to prevent (b) either the manufacturer chose not to lock the device as (or the buyer chose not to buy locked ones) and the suer was "free" to use the devices out of spec, or the article describes devices where the tests were inadequate.
In reality, device performance is not consistent within a batch, and devices are sorted for performance - hence processors with different speed and power options. This has been true since the beginning of TTL. As devices have higher part count (see Moore's law) they have a higher probability of failure - since there are more failure modes, there is a much higher time-to-test. Time to test maps directly to device cost. Because time-to-test adds to cost, semiconductor devices are not tested 100%*: some parameters are, and others are only sampled to ensure that the tests are identifying the duds. The problem here is that the parameters tested by sampling may not be as reliably characterised as they are believed to be. If you assume that (for example) all static ram cells in the chip have essentially the same logic levels and speeds within a certain margin, and that margin has a wider spread between devices under circumstances that have not been identified, then testing some sample registers won't tell you that others are not reliable on chips with this unknown and unidentified problem.
Complexity does not scale linearly with transistor count - it is partly that, but it also scales with number of modules, module complexity, and number of interfaces between modules (hardware equivalent of API's not API instances). A more complex CPU has more of all three of these factors. Any way you look at it, a more complex chip will be more likely to fail in modes that are hard to identify.
About 15 years ago, I was part of a team that identified a problem in a CPU of fairly low complexity caused by data leakage between pipeline stages in a processor used in safety critical applications (AFAIK, no one actually died as a result of these failures). These failure modes are very hard to find. This one took about a man-year of very expensive engineers using very expensive equipment.
I predict that Moore's law will eventually be hit the Thwacks Barrier: Processor complexity will reach the stage where a processor cannot be adequately tested within a timescale that makes it worth producing.
I therefore hereby, formally pronounce that testability will be the barrier that ends Moore's law.
*Some /. users who are old enough to afford lawns may recall the national Semiconductors Mil-spec scandal: devices were sold as 10% tested when in fact they were only sampled, because the failure rate was "very low". No Aircraft carriers or space rockets were actually lost, but crimes were found to be committed anyway.
Re: (Score:1)
Re: (Score:2)
I don't know, but you can probably also use any number of tries of getting a corrupted trustzone key?
Broken Hardware (Score:1)
If the power management can change the state of the processing engine then the power management methodology is broken. There should be no way to flip bits or change any of the processing state by manipulating the power state. That is is possible shows a serious flaw in the design.
Rowhammer all over again (Score:3)
This looks just like Rowhammer all over again. Flipping bits by messing with something nearby.
Re: (Score:2)
It's flipping bits by gaining root access, profiling the system, crashing it many times in the process, then mess with something nearby.
Re: (Score:2)
It's flipping bits by gaining root access, profiling the system, crashing it many times in the process, then mess with something nearby.
True, but that doesn't mean it's not bad.
The whole point of TrustZone and similar technologies is to provide a place for computations that you wish to remain secure even in the event of complete compromise of the main operating system. Note that I'm not claiming that the attack is practical, it may or may not be sufficiently automatable to carry out remotely, on a large number of devices. That's for future research to determine. But it does make me nervous (my main project for the last four years is an An
If that's all... (Score:2)
I'm actually more terrified by the notion that activities in one core can cause bits to flip for another, completely randomly. We have a _lot_ of important stuff riding on the correct calculations happening in all those CPUs, worldwide, and the idea that you can pretty trivially cause random results is not a happy one.
Not too hard to fix (Score:1)
Making things secure is much harder than breaking into things. Given that, this one is an easy fix. The hypervisor controlling security can make sure the security states are stable before granting access (Accross dvfs variations) The security software can monitor votalge varations beyond allowed and lock down the system/user program ( red alert)
Btw voltage can be varied from outside without power management commands to bypass pm control software. So a best solution is a voltage monitors (most chips have thi
Not quite so simple. (Score:2)
You need software access to the registers that control the core voltage regulators.
So you first need to gain root access.
They changed the DVFS tables to make the soc run outside it's operating areas.
They had to profile the DVFS operating points for the specific device they used to find the right values to used. The profiling causes device reboots or freezes. Not something you can do without being noticed.
Step 1: probe DVFS tables, profile system to find points where it causes bit flips without rebooting or
Is anyone beginning to get the idea (Score:2)
Semi-practical vs entrenched flaws (Score:2)
Apps cannot be granted permission to control DVFS, which is necessary to induce the faults, but they can manipulate it because Android responds to the application's load/behavior.
However, the application has no specific knowledge of the overall system load and therefore it cannot consistently induce faults. The scenario in a lab is probably far, far easier than real life---it eliminates the effect of other apps, network state changes, etc on the power state.
Very clever proof of concept, but it will take a H