Trust Issues: Exploiting TrustZone TEEs | Hacker News Reader

Trust Issues: Exploiting TrustZone TEEs

googleprojectzero.blogspot.com

142 pointsjor-el15 comments

Holy crap, that was brutal. I don't think you can get any closer to accusing someone of incompetence without actually coming out and saying so directly. If Samsung et al are this cavalier about the trust zone, what is the state of the rest of their systems, which presumably have orders of magnitude more code? Suddenly, all the reports about the thousands of bugs in tizen don't seem like exaggerations anymore.

On a different note, how does the iPhone's trust zone implementation compare? Does anyone know if it is vulnerable to similar issues?

The secure enclave processor is isolated in silicon (even the memory controller enforces access control through encryption), and Apple doesn't have to support unlocked bootloaders. SEPOS isn't simply a TEE.

There was a nice in-depth analysis of the SEE at [0]. Furthermore, Apple has been very fast in fixing security issues, and rolling out updates to all of their user base, as opposed to the "These issues probably will never be fixed, buy an S8 instead" mentality shown from the Android vendors.

[0] https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...

Indeed, SEP is a separate ARMv7 core apart from the application processor. EL3 on the AP is used for KPP. [0]

[0]: https://xerub.github.io/ios/kpp/2017/04/13/tick-tock.html

Since the “Secure World” just runs a different stack of memory-unsafe software, it’s not cool that Android’s UI characterizes TEE-based FDE key derivation as “hardware-based” “credential storage” giving the user the incorrect impression that it’s based on dedicated hardware, when, in fact, the setup is much weaker than an Apple-style Security Enclave design for FDE key derivation.

Although I was prepared to be impressed by project zero's work here I find that I'm not.

There's an efuse based revocation mechanism. It isn't used for every vulnerability. That's unfortunate but understandable-- fuses are a scarce resource. Given that, signers should be more careful about the code they sign in the first place to avoid stressing that resource.

Having said that, at the end of the day this is still just a security feature that is painful to use. That doesn't make it a vulnerability in and of itself, and dressing it up as one feels like a stretch.

It doesn't seem to have been used for any vulnerability. Including the one thats linked in the post that allow arbitrary code execution...

signers should be more careful about the code they sign in the first place

I agree with your sentiment, but that's not going to happen.

I'm not sure why not. Some of the same groups that sign this code also do formal verification of other codebases, for instance FSBLs. It seems reasonable that they would try similar approaches on TZ code given the scarcity of fuses.

Good joke. There are layers of proprietary software where nobody can audit involved. Can you trust a single auditor ever too?

Even an automated exhaustive verifier can be buggy... oot more importantly incomplete if parallelism is considered.

The best solution is to created a trusted privilege level above the TEE, that can determine whether to trust things in the TEE or not.

(Don't laugh: Intel's been adding extra security layers for years)

"Intel did it" is a pretty horrible argument, historically.

Especially with things like higher-than-OS trust levels where there are limited ABI guarantees to begin with, it might be better to redo things incompatibly if that provides a better solution than "this newly introduced mechanism of unknown quality asserts that this other mechanism of known-bad quality won't mess things up".

Intel TXT is one such "guard" mechanism. It tore larger holes in the security fabric than the mechanisms it was supposed to keep watch over.

To some extent that's how Intel SGX works, since code in an enclave (SGX name for a TEE) only executes with user level privileges and can't e.g. execute system calls.

I wonder if there could be similar exploits on AMD processors, which have a TrustZone implementation.

Samsung Security has always been abysmal and it makes me sigh, I like their hardware otherwise.

Reply on news.ycombinator.com