
On emulating hypervisors: a Samsung RKP case study - based2
http://www.phrack.org/papers/emulating_hypervisors_samsung_rkp.html
======
DyslexicAtheist
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 :)

