Slashdot Mirror
ARM TrustZone Hacked By Abusing Power Management (acolyer.org)
"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 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?
#DeleteFacebook
Don't allow non operating system code to muck with the system clock. Problem solved. Why would this functionality ever be exposed? This is something that non-OS code should NEVER be able to do.
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.
These Goldilocks voltages will vary by small margins.. too small to be accurately predicted for an actual attack.
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.
I don't read AC
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.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
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.
My Other Computer Is A Data General Nova III.
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.
My Other Computer Is A Data General Nova III.
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.
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)
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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
Could it be stopped by making appropriate amendments to the Code of Conduct?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
This looks just like Rowhammer all over again. Flipping bits by messing with something nearby.
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.
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 this)
At last , anytime you mess with dfvs beyond what the hardware was designed for , you crash the system most of the time. This is not reliable hack beyond lab controlled environment.
No, you don't understand. You're thinking of Rust as a programming language when in fact it's a religion. Every time there's some post about bugs, flaws, or bad code, the Rust flakes turn up to enlighten the heathens with their religion/language with its guarantee of perfect, error-free code and operation. All hail the mighty Rust! Lead us into the light of your perfection!
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 freezing.
Step 2: use performance counters to profile the victim code to find exactly when you need to trigger a fault
Step 3: load new values to DVFS table
Step 4: trigger a spin loop at the precise time in a core that shares the same clock-voltage values as the core the victim thread is running in, causing the system to change to the altered voltage/frequency point.
Step 5: profit?
The easiest way to mitigate this is to implement power saving better. Separate all the core frequencies and voltages, like Intel does already. The way it's done in ARM chips seems wasteful to me. why would you raise the frequency and voltage of 4 cores when you're only needing one?
You could also not allow the performance counters to be used to profile code running at a higher privilege level.
that you can't have computer security yet? That it is not possible? That what a man can make, a make can take apart?
E Proelio Veritas.
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.
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 Herculian effort to turn this into an effective attack in the wild.
Fixing the problems will require all parties. There are elements under the control of ARM directly as well as the SoC designers. Android may be able to mitigate the issues at the OS level---but I assume that would penalize battery life, system performance, or both.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.