- ARM TrustZone provides security extensions that create two virtual worlds - a normal world and a secure world. The secure world is meant to protect sensitive assets from the normal world using isolation. - Common mistakes made by developers include missing or incorrect verification of data at security boundaries, enabling debug functionality in release builds, and time-of-check/time-of-use vulnerabilities. - Public vulnerabilities have been found in the TrustZone implementations of various vendors, including issues in Huawei TrustedCore that allowed arbitrary writes to memory and Qualcomm QSEE that allowed zeroing out writable memory.

1. Security issues
with ARM TrustZone
Andrii Grygoriev
Samsung R&D Institute Ukraine

2. About me
Andrii Grygoriev
Sr. Engineer
Samsung R&D Institute Ukraine
MSc “Information security in computer systems
and networks”, KNURE, 2010
Samsung, Mobile Security Team, 2015 - now
Major responsibilities:
- software development for ARM TrustZone,
embedded secure element
- security assessment

3. Agenda
• Motivation
• Briefly about ARM TrustZone
– Example of assets that require protection
– ARM TrustZone
• Review of public CVEs
• Conclusion

4. Motivation
• Increase awareness of the ARM TrustZone
• Prevent developers from making typical mistakes
• Attract attention to proprietary TEE solutions

5. ARM TrustZone
• Set of security extensions (present
since in ARMv6)
• Two virtual worlds:
• Normal World (REE)
• Secure World (TEE)
• Sensitive assets isolation from REE
• Small Trusted Computing Base

6. EXAMPLES OF ASSETS TO
BE PROTECTED ON THE
SMARTPHONE

7. Asset: fingerprint
Personal data protection: e.g. protect user’s fingerprint from malware
Source: https://arstechnica.com/information-technology/2015/08/severe-weaknesses-in-android-handsets-could-leak-user-fingerprints/
X
NWd SWd

8. Asset: content
Content provider’s data protection on a user’s device from illegal copying
NWd SWd

9. Asset: system
Rich OS kernel protection (e.g. Samsung TIMA RKP)

10. ARM TrustZone
ARM TrustZone architecture is based on:
• AXI Bus
• ARM Core
• TrustZone Address Space Controller (TZASC)
• TrustZone Protection Controller (TZPC)

11. Protecting memory
and peripherals
ARM
CPU Core
DDR
Touch
Controller
TZASC TZPC
AMBA3 AXI BUS
Crypto
Engine

12. Communication between
REE and TEE
• CPU Registers
• Shared memory between worlds
REE TEE
Shared
Memory
non-Secure
Memory
Secure Memory
R0, R1-R6

13. Secure World privileges
Normal World Secure World
TZASC, TZPC, TZIC none yes
Physical memory only non-Secure any
Peripherals only non-Secure any
Registers non-Secure any

14. Security goals
• Secure world software MUST be protected against
attacks
• Secure world resources MUST be isolated from
Normal world
• Trusted applications MUST be isolated from each
other
• Secure kernel MUST be isolated from trusted
applications

15. Threats
• Sensitive information leak from Secure world
– Side channel attacks
– World shared buffer
– Debug logs
– Identifiers, handles
• Un-authorized code execution in Secure world
– Bypass signature verification
– Exploit software vulnerability

16. Threats (cont.)
• Privilege escalation within Secure world
– Elevate privileges from TA to the kernel
– TA breaks
• End user’s privacy violation
– Spying software in TrustZone
– Breaking disk encryption
– Stealing cryptographic keys

17. TEE app design assumptions
• REE is untrusted
• TA’s are mutually untrusted
• TEE kernel is trusted

18. Most popular TEE OSes
• Trustonic (Kinibi OS, ex. Mobicore/t-base/G&D)
[https://www.trustonic.com/]
• Qualcomm (QTEE, ex. QSEE)
[https://www.qualcomm.com/solutions/mobile-computing/features/security]
• Samsung (Teegris)
[http://developer.samsung.com/teegris]
• Huawei (TrustedCore)
[http://developer.huawei.com/consumer/cn/wiki/index.php?title=TrustedCore_%E4%B8%9A%E5%8A%A1%E4%BB%8B%E7%BB%8D]
• Linaro (OP-TEE OS)
[https://www.op-tee.org/]
• Google (Trusty)
[https://source.android.com/security/trusty/]

19. Common mistakes
• Missing or incorrect verification of data on security
boundaries
• Enabled debug functionality in release (e.g. unlock
bootloader)
• TOCTOU (Time Of Check Time Of Use)
• Leak of sensitive information (e.g. keys, addresses,
etc.)
• Incorrect usage of API (e.g. TEE, Crypto, etc.)

20. Real world examples
• Huawei Trusted Core – CVE-2015-4421,
CVE-2015-4422
• Motorola bootloader unlock
• Vuln. in HTC TZBSP custom API
• QSEE kernel vulnerability

21. Huawei TrustedCore
Target description:
• Huawei Ascend Mate7-TL10
• HiSilicon Kirin 925 SoC
• Trusted Core
• Android
Protection mechanisms in
TrustedCore OS:
• KASLRASLR – NO
• CODE SECTION – RWX
• DEP – NO
• Stack canaries – NO
Source: https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Attacking-Your-Trusted-Core-Exploiting-Trustzone-On-Android.pdf

22. Overall Architecture
Normal World
Client Application
Secure World
TZDriver(/dev/tc_ns_client) RTOSck(kernel) Fingerprint driver
GlobalTask TA_Fingerprint TA_SecStorage
TA TA TA
Secure Kernel-space
Secure User-space
Kernel-space
User-space

23. GlobalTask vulnerability
CVE-2015-4421
• GlobalTask exposes get_sys_time function to
Normal World
• get_sys_time accepts destination physical address
• input address is not verified to be non-secure
memory
• allows to write arbitrary data at arbitrary address
accessible by GlobalTask (not kernel memory)

24. GlobalTask vulnerable code

25. TrustedCore kernel vulnerability
CVE-2015-4422
• TrustedCore kernel exposes some syscall which
accepts source and destination addresses
• Missing check of input argument
• Allows attacker to modify TrustedCore kernel
memory with arbitrary data

26. TrustedCore Kernel vulnerability

27. Motorola bootloader unlock
Target description:
• Motorola Razr HD, M
• Qualcomm MSM8960
• QSEE
• Android

28. Source: http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html
Motorola SMC Handler

29. HTC TZBSP Extension
Target description:
• HTC One M7/XL
• Qualcomm MSM8960/8974
• QSEE
• Android
Protection mechanisms in
TrustedCore OS:
• KASLRASLR – NO
• CODE SECTION – RWX
• DEP – NO
• Memory mapped 1:1

30. HTC TZBSP Customization
HTC extended TZBSP with functions like this:
• tzbsp_oem_do_something
• tzbsp_oem_enc
• tzbsp_oem_get_rand
• tzbsp_oem_log_operator
• tzbsp_oem_hash
• tzbsp_oem_set_simlock_retry
• tzbsp_oem_get_security_level
• tzbsp_oem_verify_bootloader
• tzbsp_oem_aes

31. HTC TZBSP Customization
[tzbsp_oem_discretix]
• no input arguments validation
• it is possible to overwrite arbitrary memory with zero

32. HTC TZBSP Customization
[tzbsp_oem_memcpy]
ZERO opcode on ARM32 is NOP
• 00 00 = MOV r0, r0
• 00 00 00 00 = ANDEQ r0, r0, r0
Since the body of that function is writable
attacker can simply overwrite all checks with
NOPs using tzbsp_oem_discretix function.
As a result, this function turns into memcpy.

33. QSEE Kernel Vulnerability
Target description:
• Nexus 5
• Qualcomm MSM8974
• QSEE
• Android

34. QSEE Kernel Vulnerability
[tzbsp_es_is_activated]
• no input arguments validation
• allows to zeroize any writable memory

35. Boomerang
by ucsb-seclab
Source: https://github.com/ucsb-seclab/boomerang

36. Boomerang
• NWd and SWd have independent mappings
• SWd has access to any physical memory
• NWd provides physical address of memory for
processing (e.g. buffer to encrypt, destination
buffer)
• Security issue: NWd can trigger SWd to access
target memory, e.g., user-space application can
trigger SWd to modify kernel memory

37. Boomerang flaw

38. Boomerang flaw
TEE Name Vendor Impact Bug Details
TrustedCore Huawei Arbitrary write CVE-2016-8762
QSEE Qualcomm Arbitrary write CVE-2016-5349
Trustonic As used by Samsung Arbitrary write PZ-962
Sierra TEE Sierraware Arbitrary write No resposne from
vendor
OP-TEE Linaro Write to other
application’s memory
Github issues 13,14

39. Conclusions
• If software is executed in Secure World – it doesn’t
mean the software is secured
• TCB is huge and it’s expanding
• Lack of security countermeasures results in easier
exploitation vulnerability in Secure World software
than in Rich OS
• Code execution in TEE gives full control over NWd
• TrustZone is becoming an attractive target for attackers

40. Questions?

41. Thank you