We have written extensively about remote baseband vulnerability research in the past, examining various vendors’ baseband OS micro-architectures and exploring their implementations for remotely exploitable bugs. So have many others. One might say, our research exists in the context in which it lives and what came before it: whether it be about finding (1, 2, 3, 4, 5, 6, 7) or exploiting (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14) vulnerabilities. However, one area that has been absent from prior art was a direct examination of lower layers of Radio Layer protocols for security vulnerabilities.

In our previous blog post, we have introduced our latest research into full chain baseband exploits. We have showcased new research tools (our nanoMIPS decompiler, debugger, and emulator for Mediatek basebands) and explored the interconnected components across the Cellular Processor and the Application Processor of Samsung and Mediatek radio interface stacks. The most serious of vulnerabilities in these interfaces can lead to over-the-air exploitation of the device: zero-click remote code execution not only in the baseband, but in the Android runtime as well. It’s no secret that baseband full-chains of this kind have existed privately and been used In-The-Wild, as recently documented by the “Predator Files” disclosures, for example.

Talks about baseband vulnerabilities are certainly in fashion these days. However, most publications so far omit the step of escaping the baseband runtime. With the novelty of baseband-only vulns wearing off, we decided to look at some popular targets (Samsung and MediaTek smartphones) with full chain exploitation in mind. Over the last year, our research has resulted in a dozen+ CVEs, including both remote code execution vulnerabilities and baseband-to-Android pivot vulnerabilities. I will be presenting the details of our work at the upcoming Hardwear.io conference, where we’ll also deliver a training on the subject. Full vulnerability details will be held back until the conference at vendor request.

Introduction Last summer I have discovered several vulnerabilities in the implementation of Samsung’s NPU device driver. While I was working on completing my proof of concept exploit, Ben Hawkes from Google’s Project Zero reported the same vulnerabilities to Samsung. Later that year Brandon Azad released an article documenting his approach of turning these bugs into an arbitrary kernel code execution exploit. At the same time, the team of aSiagaming, yeonnic, and say2 also found the same bugs and published a writeup, focusing on their method of exploitation and the post exploitation steps required to obtain root. What makes the initial bugs interesting, besides the triple collision, is that they provide two very distinct avenues for exploitation.

Summary This is the third part of a blog series covering my security research into Samsung’s TrustZone. This post covers the following vulnerabilities that I have found: SVE-2017–8888: Authentication Bypass + Buffer overflow in tlc_server SVE-2017–8889: Stack buffer overflow in ESECOMM Trustlet SVE-2017–8890: Out-of-bounds memory read in ESECOMM Trustlet SVE-2017–8891: Stack buffer overflow in ESECOMM Trustlet SVE-2017–8892: Stack buffer overflow in ESECOMM Trustlet SVE-2017–8893: Arbitrary write in ESECOMM Trustlet You can find all the PoCs on github. Target Selection The first thing for me was deciding on Trustlets to focus on. I can not emphasize enough: if you build on some other way of getting to system level privileges, tons of new Trustlet-level attack surface opens up.

Summary This is the second part of a blog series covering my security research into Samsung’s TrustZone. This post is a companion to my talk from Ekoparty 2017, namely the reverse engineering process of T-base. The slides and video of the talk are both available online. In fact, since both of those are available, for this part of the series I didn’t quite write a “storytelling” blog post. Instead, this post only does what the slide/video format does not accomplish: a more accessible enumeration of the most important results (code snippets, declarations of reversed functions/structures). So it’s more like a wiki then a blog post.

Summary 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.