Does it just mean that people can root all devices using this chipset? Or something worse?
(sorry if this is obvious, I'm just not in the know)
I'm not 100% sure if KM is only used to store "user" keys such as encryption keys for FDE or does it also has access to other keys stored on the hardware key storage such as the ones used to verify the firmware and OS images allowing you to bypass vendor restrictions that prevent running unsigned bootloaders, firmware, and OS images on the device.
That said QM's TrustZone kernel AFAIK pretty much runs as root (and somewhat even higher) so ACE vulnerabilities in it can be effectively used to execute any command with root or higher privileges regardless if you can fully "root" the phone or not.
Including all iPhones sold today. Bye bye secure enclave. Bye bye full disk encryption.
Considering the previous publications by this author the issue is most likely within the TZ Kernel that QM uses not in the hardware itself, previous vulnerabilities that were disclosed by the same guy/gal/singular or plural sentient entity were patched.
Even worse than their version that works with a hardware secure enclave is the version which works without one.
How does that one work? By ensuring that the user didn’t modify the OS image.
That’s literally all security there is.
It’d be a lot better if they’d just build a security model that doesn’t have to rely on the device being secure, but instead rely on the banks’ servers being secure.
I can thank some US banks that I, as German Android user, get locked down by Google. I get all the issues, none of the benefits.
One source of many:
In particular this line in the screenshot hints at what he did: "Overwriting syscall_table_5 pointer"
The issue is likely applicable on particular qualcomm devices, and a software patch should be possible.
Unfortunately the constant stream of hacks of TrustZone applets that amount to "I smashed a buffer on the stack and got access" make me think that too often people forget the "more auditable" part.
If it's not, well, uhh, yeah this is kind of a problem.
It's more likely than not just a flaw within Keymaster itself, or within the Trustzone Kernel which means that this can effectively be patched, this isn't the first time vulnerabilities like this have been identified (same author) and previous issues have been patched.
For anyone who wonders TrustZone is a Trusted Execution Environment (TEE) technology for ARM CPU's the more known equivalent is probably Intel's TXT, it's not something QM has (solely) developed internally and an underlying issue with TZ can affect many more SOC's than just QM's (since AMD also uses TrustZone this could potentially also affect desktop/server CPU's).
My personal bet would be that this is an issue with Keymaster, or the TZ Kernel that QM has built not with TZ itself on a hardware or even microcode level and most likely very possible to be patched.
If it's present, this is used by apps like 'Google Authenticator' and 'Symantec Vip access' to store credentials in such a way that they can't be copied off the device or backed up.
When this technology works perfectly, the idea is if you have a short passcode and someone steals your phone, they can't extract the encrypted data and brute-force the passcode without an electron microscope and a team of engineers.
Unfortunately, it can also be used for user-hostile applications like providing DRM and preventing backups and rooting.
I was wrong about Google Authenticator. I assumed it was the same as Symantec because of all the people online complaining about being unable to back up their credentials.
iPhones don't use it. They don't use Qualcomm SOC's.
(But yes, he is a troll and this whole case has nothing to do with Apple).
TrustZone is an ARM thing, and the iPhone Secure Enclave is indeed built on TrustZone.
Apple do not use Qualcomm and this a Qualcomm-specific bug. But Apple do use their own modded TrustZone.
Despite widespread rumour to the contrary, the secure enclave on iPhones is a separate core, not just TrustZone on the main CPU.
With TrustZone, some code is running in the secure domain and can read or write to both secure and non-secure memory. You need to find some bug in the secure code to "trick" the secure code into copying data from secure memory to non-secure memory.
(... unless you are one)
A little context wouldn't have hurt anyone.
I think to most people following him, it's clear this is about ARM TrustZone.
E: ah, my original post is missing a negation. Too late to edit.
Edit: many in this thread appear to be missing critical context, as the secure enclave is not in play.
Iphone 5c has qualcomm stuff in it.