
Trust Issues: Exploiting TrustZone TEEs - jor-el
https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html
======
Lx1oG-AWb6h_ZG0
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?

~~~
tptacek
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.

~~~
ge0rg
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...](https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-
The-Secure-Enclave-Processor.pdf)

------
hsivonen
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.

------
debatem1
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.

~~~
ktRolster
_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.

~~~
debatem1
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.

~~~
AstralStorm
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.

------
ktRolster
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)

~~~
pgeorgi
"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.

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

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

