Re: https://firmwaresecurity.com/2018/06/19/quarkslab-intro-to-tee-arms-trustzone/
https://blog.quarkslab.com/attacking-the-arms-trustzone.html
Tag: TrustZone
QuarksLab: intro to TEE: ARM’s TrustZone
[…]This starts a series of two blogposts discussing hardware technologies that can be used to support TEE implementations:
* TrustZone from ARM
* SGX from Intel
As suggested by the title, this blogpost tells you more about TrustZone.[…]
https://blog.quarkslab.com/introduction-to-trusted-execution-environment-arms-trustzone.html
Google Asylo: SDK for apps that run in TEEs
[…]Today we’re excited to announce Asylo (Greek for “safe place”), a new open-source framework that makes it easier to protect the confidentiality and integrity of applications and data in a confidential computing environment. Asylo is an open-source framework and SDK for developing applications that run in trusted execution environments (TEEs). TEEs help defend against attacks targeting underlying layers of the stack, including the operating system, hypervisor, drivers, and firmware, by providing specialized execution environments known as “enclaves”. TEEs can also help mitigate the risk of being compromised by a malicious insider or an unauthorized third-party. Asylo includes features and services for encrypting sensitive communications and verifying the integrity of code running in enclaves, which help protect data and applications.[…]
Reversing/exploiting Samsung’s TrustZone, part 1
Unbox Your Phone — Part I.
This is the first part of a blog series about reverse engineering and exploiting Samsung’s TrustZone. Following parts in the series so far: 2, 3. This first post covers the basics of the architecture. All of this is public info, nothing new, all of it has been covered in bits and pieces in various publications before. Some of it comes from Trustonic/Samsung materials, some of it from open source software, and some of it from the few great instances of prior research. It’s here as an intro, for completeness. Later in the series, I summarize the reverse engineering results and explain the vulnerabilities that I have found.[…]
Aleph Security: Firehorse: Research & Exploitation framework for Qualcomm EDL (Firehose)
Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
By Roee Hay (@roeehay) & Noam Hadad
January 22, 2018
* QPSIIR-909, ALEPH-2017029, CVE-2017-13174, CVE-2017-5947
There are many guides across the Internet for ‘unbricking’ Qualcomm-based mobile devices. All of these guides make use of Emergency Download Mode (EDL), an alternate boot-mode of the Qualcomm Boot ROM (Primary Bootloader). To make any use of this mode, users must get hold of OEM-signed programmers, which seem to be publicly available for various such devices. While the reason of their public availability is unknown, our best guess is that these programmers are often leaked from OEM device repair labs. Some OEMs (e.g. Xiaomi) also publish them on their official forums. […] In this 5-part blog post we discuss the security implications of the leaked programmers. The first part presents some internals of the PBL, EDL, Qualcomm Sahara and programmers, focusing on Firehose. In Part 2, we discuss storage-based attacks exploiting a functionality of EDL programmers – we will see a few concrete examples such as unlocking the Xiaomi Note 5A (codename ugglite) bootloader in order to install and load a malicious boot image thus breaking the chain-of-trust. Part 3, Part 4 & Part 5 are dedicated for the main focus of our research – memory based attacks. In Part 3 we exploit a hidden functionality of Firehose programmers in order to execute code with highest privileges (EL3) in some devices, allowing us, for example, to dump the Boot ROM (PBL) of various SoCs. We then present our exploit framework, firehorse, which implements a runtime debugger for firehose programmers (Part 4). We end with a complete Secure-Boot bypass attack for Nokia 6 MSM8937, that uses our exploit framework. We achieve code execution in the PBL (or more accurately, in a PBL clone), allowing us to defeat the chain of trust, gaining code execution in every part of the bootloader chain, including TrustZone, and the High Level OS (Android) itself.
The merit of our research is as follows:
* We describe the Qualcomm EDL (Firehose) and Sahara Protocols. (Part 1)
* We created firehorse, a publicly available research framework for Firehose-based programmers, capable of debugging/tracing the programmer (and the rest of the bootloader chain, including the Boot ROM itself, on some devices). (Part 3 & Part 4)
* We obtained and reverse-engineered the PBL of various Qualcomm-based chipsets (MSM8994/MSM8917/MSM8937/MSM8953/MSM8974) using the Firehose programmers and our research framework. (Part 3)
* We obtained the RPM & Modem PBLs of Nexus 6P (MSM8994). (Part 3)
* We managed to unlock & root various Android Bootloaders, such as Xiaomi Note 5A, using a storage-based attack only. (Part 2)
* We managed to manifest an end-to-end attack against our Nokia 6 device running Snapdragon 425 (MSM8937). We believe this attack is also applicable for Nokia 5, and might be even extensible to other devices, although unverified. (Part 5)
Research & Exploitation framework for Qualcomm EDL Firehorse programmers
https://github.com/alephsecurity/firehorse
Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
https://alephsecurity.com/2018/01/22/qualcomm-edl-1/
Exploiting Qualcomm EDL Programmers (2): Storage-based Attacks & Rooting
https://alephsecurity.com/2018/01/22/qualcomm-edl-2/
Exploiting Qualcomm EDL Programmers (3): Memory-based Attacks & PBL Extraction
https://alephsecurity.com/2018/01/22/qualcomm-edl-3/
Exploiting Qualcomm EDL Programmers (4): Runtime Debugger
https://alephsecurity.com/2018/01/22/qualcomm-edl-4/
Exploiting Qualcomm EDL Programmers (5): Breaking Nokia 6’s Secure Boot
https://alephsecurity.com/2018/01/22/qualcomm-edl-5/
NCC Group releases Cachegrab, tool for trace-driven cache attacks against ARMv8 TrustZone
34C3 Tool Release: Cachegrab
Today, NCC Group is releasing Cachegrab, a tool designed to help perform and visualize trace-driven cache attacks against software in the secure world of TrustZone-enabled ARMv8 cores. These cache attacks, as well as other microarchitectural attacks on secure computing environments, were presented at the 34th Chaos Communication Congress. There are two key properties of many TrustZone implementations that make the attacks within Cachegrab feasible. First, the secure world and non-secure world often share the caches within a processor. This means that when software executes in the secure world, it affects the presence or absence of non-secure world entries within the shared cache. Second, privileged users in the non-secure world are able to use privileged instructions to interleave attacker and victim processes, as well as determine what non-secure data has been evicted from the cache.[…]
https://github.com/nccgroup/cachegrab
https://events.ccc.de/congress/2017/Fahrplan/events/8950.html
ARM releases Platform Security Architecture
ARM has announced a Platform Security Architecture.
As well, they’ve announced the ARM CryptoIsland family of TrustZone family.
And they’ve announced the ARM CoreSight SDC-600 Secure Debug Channel, which provides a dedicated path to a debugged system for authenticating debug accesses.
https://www.arm.com/news/2017/10/a-common-industry-framework
https://developer.arm.com/products/architecture/platform-security-architecture
https://developer.arm.com/products/system-ip/trustzone-security-ip/cryptoisland-family
CLKSCREW: breaking TEEs with energy mgmt
CLKSCREW: Exposing the perils of security-oblivious energy management
https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang
0x0atang.github.io/files/usenix17_clkscrew_preprint.pdf
https://hacks.hyperspacer.com/app/items/15303894
vTZ: Virtualizing ARM TrustZone
https://twitter.com/security_Kiwi/status/894174335493124096
vTZ: Virtualizing ARM TrustZone
Zhichao Hua, Jinyu Gu, Yubin Xia, Haibo Chen, Binyu Zang, Haibing Guan
ARM TrustZone, a security extension that provides a secure world, a trusted execution environment (TEE), to run security-sensitive code, has been widely adopted in mobile platforms. With the increasing momentum of ARM64 being adopted in server markets like cloud, it is likely to see TrustZone being adopted as a key pillar for cloud security. Unfortunately, TrustZone is not designed to be virtualizable as there is only one TEE provided by the hardware, which prevents it from being securely shared by multiple virtual machines (VMs). This paper conducts a study on variable approaches to virtualizing TrustZone in virtualized environments and then presents vTZ, a solution that securely provides each guest VM with a virtualized guest TEE using existing hardware. vTZ leverages the idea of separating functionality from protection by maintaining a secure co-running VM to serve as a guest TEE, while using the hardware TrustZone to enforce strong isolation among guest TEEs and the untrusted hypervisor. Specifically, vTZ uses a tiny monitor running within the physical TrustZone that securely interposes and virtualizes memory mapping and world switching. vTZ further leverages a few pieces of protected, self-contained code running in a Constrained Isolated Execution Environment (CIEE) to provide secure virtualization and isolation among multiple guest TEEs. We have implemented vTZ on Xen 4.8 on both ARMv7 and ARMv8 development boards. Evaluation using two common TEE-kernels (secure kernel running in TEE) such as seL4 1 and OP-TEE shows that vTZ provides strong security with small performance overhead.
Aleph Security: Secure Boot vuln in Qualcomm OnePlus 2
OnePlus 2 Lack of SBL1 Validation Broken Secure Boot
Aleph Research Advisory
CVE-2017-11105
OnePlus 2 (a 2015 Qualcomm Snapdragon 810 device) successfully boots with a tampered Secondary Bootloader (sbl1) partition although it is digitally-signed, hence it is not validated by its Primary Bootloader (PBL), maybe due to lenient hardware configuration. Attackers capable of tampering with the sbl1 partition can then disable the signature validation of the rest of the bootloader chain and other SBL-validated partitions such as TrustZone and ABOOT.[…]
https://alephsecurity.com/vulns/aleph-2017026
https://alephsecurity.com/2017/05/11/oneplus-ota/
https://oneplus.net/
https://nvd.nist.gov/vuln/detail/CVE-2016-10370
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8850
https://github.com/OnePlusOSS
https://oneplus.net/2/oxygenos
Trust Issues: Exploiting TrustZone TEEs
by Gal Beniamini, Project Zero
Mobile devices are becoming an increasingly privacy-sensitive platform. Nowadays, devices process a wide range of personal and private information of a sensitive nature, such as biometric identifiers, payment data and cryptographic keys. Additionally, modern content protection schemes demand a high degree of confidentiality, requiring stricter guarantees than those offered by the “regular” operating system. In response to these use-cases and more, mobile device manufacturers have opted for the creation of a “Trusted Execution Environment” (TEE), which can be used to safeguard the information processed within it. In the Android ecosystem, two major TEE implementations exist – Qualcomm’s QSEE and Trustonic’s Kinibi (formerly <t-base). Both of these implementations rely on ARM TrustZone security extensions in order to facilitate a small “secure” operating system, within which “Trusted Applications” (TAs) may be executed. In this blog post we’ll explore the security properties of the two major TEEs present on Android devices. We’ll see how, despite their highly sensitive vantage point, these operating systems currently lag behind modern operating systems in terms of security mitigations and practices. Additionally, we’ll discover and exploit a major design issue which affects the security of most devices utilising both platforms. Lastly, we’ll see why the integrity of TEEs is crucial to the overall security of the device, making a case for the need to increase their defences. […]
https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html
Attacking ARM TrustZone using RowHammer
Samsung TrustZone vulnerability from ChromeOS
Samsung TrustZone vulnerability
Morpheus’ ARM TrustZone research
Click on link in tweet for slides.
QSEE TrustZone exploitation
TrustZone Kernel Privilege Escalation (CVE-2016-2431)
In this blog post we’ll continue our journey from zero permissions to code execution in the TrustZone kernel. Having previously elevated our privileges to QSEE, we are left with the task of exploiting the TrustZone kernel itself.
“Why?”, I hear you ask. Well… There are quite a few interesting things we can do solely from the context of the TrustZone kernel. To name a few:
* We could hijack any QSEE application directly, thus exposing all of it’s internal secrets. For example, we could directly extract the stored real-life fingerprint or various secret encryption keys (more on this in the next blog post!).
* We could disable the hardware protections provided by the SoC’s XPUs, allowing us to read and write directly to all of the DRAM. This includes the memory used by the peripherals on the board (such as the modem).
* As we’ve previously seen, we could blow the QFuses responsible for various device features. In certain cases, this could allow us to unlock a locked bootloader (depending on how the lock is implemented).
So now that we’ve set the stage, let’s start by surveying the attack surface! […]
https://bits-please.blogspot.com/2016/06/trustzone-kernel-privilege-escalation.html
QualComm TrustZone MasterKeys extracted?
Kindly pointed out by a reader of the blog, laginimaineb has some more research going on for QualComm TrustZone, sounds non-trivial:
[Grr, when I paste an URL of a Twitter tweet, WordPress usually renders it, today, it is not, maybe it will before it posts it, unsure. I’ve extracted the text from the Tweets in case it does not.]
Just managed to extract the Qualcomm KeyMaster keys directly from TrustZone! Writeup coming soon 🙂 (1/2)
And wrote a script to decrypt all keystore keys. This can also be used to bruteforce the FDE passphrase off the device! (2/2)
This specifically is done on the Nexus 6, but I’ve also dabbled w/ the Nexus 5 and Moto X 2nd Gen
https://mobile.twitter.com/laginimaineb/status/737051964857561093
https://mobile.twitter.com/laginimaineb/status/737052350674817024
https://mobile.twitter.com/laginimaineb/status/737185999760052224
https://mobile.twitter.com/laginimaineb/status/737186295655596032
https://mobile.twitter.com/laginimaineb/status/737188674371215360
More info:
https://mobile.twitter.com/laginimaineb
http://bits-please.blogspot.co.il/2016/05/qsee-privilege-escalation-vulnerability.html
http://bits-please.blogspot.co.il/2016/05/qsee-privilege-escalation-vulnerability.html
http://bits-please.blogspot.com/
new Microsoft ACPI table: WSMT
As mentioned earlier this week, Microsoft just released a spec for their new ACPI table WSMT (Windows SMM Security Mitigations Table):
https://firmwaresecurity.com/2016/04/20/windows-smm-security-mitigations-table/
The Windows SMM Security Mitigations Table specification contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. This information applies for Windows Server Technical Preview 2016, and Windows 10, version 1607. […]
Full spec:
http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx
The UEFI Forum maintains ACPI specs. AFAICT, their ACPI spec list does not yet list this new WSMT table.
http://www.uefi.org/acpi
Also, there’s a strange copyright in this spec:
Portions of this software may be based on NCSA Mosaic. NCSA Mosaic was developed by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc.
Maybe I am just noticing this paragraph, and Microsoft always uses that on copyright pages, and does not mention other old software, only NCSA Mosaic. But why NCSA Mosaic-centric copyrights in an WSMT ACPI table?? Microsoft IE 1.0 was based on NCSA Mosaic source code, via Spyglass purchase, but that was long before EFI or ACPI. I didn’t notice anything Win9x/BIOS/ISA-PNP-centric about WSMT. :-).
In related news, Jiewen Yao of Intel has submitted the WSMT definition into the tianocore EDK-II project:
MdePkg: Add WSMT definition. This patch adds Windows SMM Security Mitigation Table @ http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx
…/WindowsSmmSecurityMitigationTable.h | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
+#define EFI_ACPI_WINDOWS_SMM_SECURITY_MITIGATION_TABLE_SIGNATURE SIGNATURE_32(‘W’, ‘S’, ‘M’, ‘T’)
Jiewen also submitted a 12-part patch, enhancing SMM to deal with this new table:
[PATCH 00/12] Enhance SMM Communication by using fixed comm buffer. This series patches are generate to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS requirement. Before this series patches, the DXE or OS module can use any non-SMM memory as communication buffer to exchange data with SMM agent. Microsoft WSMT table has requirement to support fixed communication buffer – so that SMM agent can only support communication buffer with type EfiReservedMemoryType/EfiRuntimeServicesCode/EfiRuntimeServicesData/EfiACPIMemoryNVS, which will not be used by OS during runtime. So we clean up all SMM handler to only use these memory regions for SMM communication, and enhance check in SmmMemLib to catch the violation. This series patches are validated on real platforms with SMM enabled. This series patches are validated on OVMF ia32-x64 with SMM enabled.
For full patch, see list archives:
https://lists.01.org/mailman/listinfo/edk2-devel
Motorola bootlocker unlocking
Unlocking the Motorola Bootloader
In this blog post, we’ll explore the Motorola bootloader on recent Qualcomm Snapdragon devices. Our goal will be to unlock the bootloader of a Moto X (2nd Gen), by using the TrustZone kernel code execution vulnerability from the previous blog posts. Note that although we will show the complete unlocking process for this specific device, it should be general enough to work at-least for most modern Motorola devices. […]
Full post:
http://bits-please.blogspot.com/2016/02/unlocking-motorola-bootloader.html
Zero perms to TrustZone: Android mediaserver CVEs discussion
https://pbs.twimg.com/media/CZgC2lkUEAA16RP.png:large
Android privilege escalation to mediaserver from zero permissions (CVE-2014-7920 + CVE-2014-7921)
In this blog post we’ll go over two vulnerabilities I discovered which, when combined, enable arbitrary code execution within the “mediaserver” process from any context, requiring no permissions whatsoever. How bad is it? The first vulnerability (CVE-2014-7921) was present in all Android version from 4.0.3 onwards. The second vulnerability (CVE-2014-7920) was present in all Android versions from 2.2 (!). Also, these vulnerabilities are not vendor specific and were present in all Android devices. Since the first vulnerability is only needed to bypass ASLR, and ASLR is only present (in a meaningful form) from Android 4.1 onwards, this means that these vulnerabilities allow code execution within “mediaserver” on any Android device starting from version 2.2. Although I reported both vulnerabilities in mid October 2014, they were unfortunately only fixed much later (see “Timeline” for full description, below) – in Android version 5.1! This means that there are many devices out there which are still vulnerable to these issues, so please take care. You can find the actual patches here. The patches were pushed to AOSP five months after the vulnerabilities were reported. That said, the Android security team was very pleasant to work with, and with other vulnerabilities I reported later on, were much more responsive and managed to solve the issues within a shorter time-frame.
[…]
Full post:
http://bits-please.blogspot.com/2016/01/android-privilege-escalation-to.html
Sigh, it seem harder to track ARM firmware bugs, since they’re often hidden in the description of an app bug. And SCAP has no firmware OVAL definitions for CVEs to mention things like TrustZone. 😦
Firmware Security 
You must be logged in to post a comment.