54+ upvotes and no comments so I'll share some things I learned about ARM TrustZone (notes I took when studying it - very sorry about formatting - direct copy from a markdown file) - sorry if these are noob or very obvious takeaways (they certainly are compared to the phrack article, but here goes) ...
TZ is is not tamper-resistant hardware like eSE or UICC. And it is heavily implementation dependant (e.g. Qualcomm, Samsung, HTC, Mobicore etc)
> "To defeat the TrustZone one must first break out of the FriendZone" --unknown
- TrustZone security depends on the provider who implemented it
- not much existing security research unfortunately
- can be abused to store rootkits
- reading from disk can be exploited (eMMC Flash) due to parsing vulns
- vulns in the Trustlets themselvs are possible (trustlets are isolated so damage is limited to the Trustlet)
- attacks assume local admin access (root) since you need ability to issue SMC instructions
- arbitrary code execution can probably be ignored since very limited, otherwise no ability to interact with TrustZone
theoretically:
- SCM Command structures can be abused (kernel sends malicious command buffer which might cause integer overflow, e.g. > 0xffffff)
- SMC request to exploit integer overflow which causes QSEE to write response header to arbitrary secure memory!
- resulting hopefully in arbitrary secure code execution (only theoretically)
- not so easy to exploit, however QSEE memory layout is known. Its image resides unencrypted on eMMC flash and is loaded at known physical address. A determined attacker can clobber part of a function pointer in secure memory to point to non-secure memory under control of attacker (e.g. payload)
but in practice:
- it's a dead end since QSEE has mechanism to prevent TrustZone execution from non-secure pages (XPU?). This is undocumented and so remains only a theoretical attack for now.
however, you can achieve glory with attacking SMC Table Extension:
- enumerate SMC handlers, and eliminate those that don't write putput, then chose best option based on task at hand. In SMC they are variable length (struct smc_entry), so you can actually iterate through table using num_tags to calculate entry length and matching against smc_num.
- Essentially if you use arbitrary secure memory write to modify num_args filed in SMC table entry. Then expand size of entry so iterator jumps to supposed next entry in attacker controlled con-secure memory, and create fake entry to call arbitrary QSEE functions with arbitrary arguments!
- One could find memcpy() and copy all of secure memory to a non-secure buffer, break all DRM/secure key storage, disable TIMA, or invoke OEM specific functionality (unlock bootloader permanently and/or install rootkit invisible to kernel)
- now you have total control of EL2 TZ and hide malware which can never be found by the OS :)
TZ is is not tamper-resistant hardware like eSE or UICC. And it is heavily implementation dependant (e.g. Qualcomm, Samsung, HTC, Mobicore etc)
> "To defeat the TrustZone one must first break out of the FriendZone" --unknown
- TrustZone security depends on the provider who implemented it
- not much existing security research unfortunately
- can be abused to store rootkits
- reading from disk can be exploited (eMMC Flash) due to parsing vulns
- vulns in the Trustlets themselvs are possible (trustlets are isolated so damage is limited to the Trustlet)
- attacks assume local admin access (root) since you need ability to issue SMC instructions
- arbitrary code execution can probably be ignored since very limited, otherwise no ability to interact with TrustZone
theoretically:
- SCM Command structures can be abused (kernel sends malicious command buffer which might cause integer overflow, e.g. > 0xffffff)
- SMC request to exploit integer overflow which causes QSEE to write response header to arbitrary secure memory!
- resulting hopefully in arbitrary secure code execution (only theoretically)
- not so easy to exploit, however QSEE memory layout is known. Its image resides unencrypted on eMMC flash and is loaded at known physical address. A determined attacker can clobber part of a function pointer in secure memory to point to non-secure memory under control of attacker (e.g. payload)
but in practice:
- it's a dead end since QSEE has mechanism to prevent TrustZone execution from non-secure pages (XPU?). This is undocumented and so remains only a theoretical attack for now.
however, you can achieve glory with attacking SMC Table Extension:
- enumerate SMC handlers, and eliminate those that don't write putput, then chose best option based on task at hand. In SMC they are variable length (struct smc_entry), so you can actually iterate through table using num_tags to calculate entry length and matching against smc_num.
- Essentially if you use arbitrary secure memory write to modify num_args filed in SMC table entry. Then expand size of entry so iterator jumps to supposed next entry in attacker controlled con-secure memory, and create fake entry to call arbitrary QSEE functions with arbitrary arguments!
- One could find memcpy() and copy all of secure memory to a non-secure buffer, break all DRM/secure key storage, disable TIMA, or invoke OEM specific functionality (unlock bootloader permanently and/or install rootkit invisible to kernel)
- now you have total control of EL2 TZ and hide malware which can never be found by the OS :)