Recently we have disclosed new advisories related to the remote exploitation of Huawei smartphones. The research that led to these findings was motivated by analyzing new interfaces for remote code execution on a mobile platform. After our work on exploiting Huawei’s Kirin via its baseband interface, we wanted to explore the possibilities of logic bugs as RCE vectors in a modern smartphone chipset, as opposed to memory corruption scenarios that are more common in public research. Logic bugs can be the most powerful because they have the potential to bypass almost all the exploit mitigations that are the typical focus these days, like ASLR, N^X, sandboxing parser code, etc.

This summer at Black Hat, we have published research about exploiting Huawei basebands (video recording also available here). The remote code execution attack surface explored in that work was the Radio Resource stack’s CSN.1 decoder. Searching for bugs in CSN.1 decoding turned out to be very fruitful in the case of Huawei’s baseband, however, they were not the only vendor that we looked at - or that had such issues. Around at the same time that we investigated Huawei’s baseband, we also looked into the same attack surface in the baseband of MediaTek Helio chipsets. As the timelines in our advisories (1, 2, 3, 4) show, these vulnerabilities were reported way back in December 2019 and the MediaTek security advisories were released in September 2021 initially and updated in January 2022.

Today we share a fun little Huawei bug that adds a twist to our previous forays into Neural Networking-based exploitation of Android devices. In previous posts, we have shown that the Neural Networking features of modern Android devices can lead to serious - if quite traditional - vulnerabilities. This time, we present a vulnerability in which Machine Learning is not the culprit - but the tool we use to actually exploit a seemingly minor permission misconfiguration issue! Introduction This time last year while auditing vendor-specific filesystem node access rights, we’ve spotted an SELinux permission misconfiguration issue that, at first, looked somewhat innocuous: all untrusted applications could access a sysfs-based log file of condensed haptic event statistics.

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.