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
Would using the Rust programming language help to avoid these problems that are happening between two different threads of execution? As is stated on the Rust web site front page, one of Rust's benefits is that it has "threads without data races" and it also has "guaranteed memory safety". Both of those sound like they could go along way toward helping prevent one thread of execution interfering with another.
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.
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
It's getting to the point where I kind of yawn when the daily data heist is posted. Like Equifax's sheer idiocy and incompetence is not surprising any more.
But this one, yeah, it's so devious that it makes you sit up and say oh shit, is there really anything that can be made practically secure these days? We rest on our laurels by saying 1024 bits is perfectly fine until quantum computers come around, yada yada.
But this one is like taking down Hoover dam by twisting a screwdriver in one strategic crack. It's using physics to coax math.
With a ton of smart, dedicated crackers all around the world, how many truly devious exploits have been thought up for attacking secure enclave, for example?
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.
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.
RTFM, idiot, the clock is manipulated by the order of executed instructions, problem is NOT solved.
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
Thank you so much for being your lovable talented self, EditorDavid.
Now if you refrain from tacking on empty scareword headlines while trying to find content we might actually have some indication the linked article might be worhty of reading instead of clickbait.
But then, you're all about the clickbait, aren't you?
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.
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.
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.