Recently we have presented our research on the remote exploitation of Huawei basebands at Black Hat USA 2021. As part of our findings, we have identified several bootloader vulnerabilities in Huawei Kirin chipsets. In addition to that publication, we have also recently disclosed an additional bootrom vulnerability (CVE-2021-22429) in Huawei Kirins. As it has been publicized, many of these bootloader vulnerabilities were present in bootrom code. As such, it can come as a surprise that Huawei in fact created a mitigation which was published just before Black Hat, in a July OTA update (updates started from June 29th, to be precise).
Samsung’s neural processing framework has received a lot of attention from the security community since its introduction. Hardware isolation vulnerabilities have been demonstrated, both on the NPU and DSP cores (1, 2), that could be used to compromise the kernel. The surrounding kernel code was also exploited by multiple researchers to gain local privilege escalation (1, 2). I, too, explored in a previous blog post how a kmalloc overflow within the Samsung NPU kernel driver can be exploited to gain arbitrary kernel read/write access. As a follow up work, I’ve decided to investigate Huawei’s implementation of their neural processing framework. Despite being the second largest vendor on the Android market, recently there have been lot fewer technical papers published about the security of their devices.
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.