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! […]



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


More info:


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):


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:

The UEFI Forum maintains ACPI specs. AFAICT, their ACPI spec list does not yet list this new WSMT table.

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(+)


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: