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.

Additional posts in this series: Part 1 Part 3 If you’ve watched my Basebanheimer talk, you will have noticed that concrete ideas for exploiting CVE-2022-21744, a heap buffer overflow in Mediatek baseband, were omitted from the talk for brevity. This heap overflow vulnerability has an important limitation: the overwriting value is a pointer to an allocation with attacker controlled bytes. In other words, as explained in the talk, we aren’t controlling the bytes we corrupt with directly, we write 4 byte pointer values that each point to an allocation with content controlled by the attacker. This creates new challenges, since the Mediatek heap exploitation techniques that we disclosed in 2022 would not apply directly due to the nature of our overwrite primitive.

Additional posts in this series: Part 1 Part 2 In my Basebanheimer talk at Hardwear.io, I explained a method for exploiting the Mediatek Baseband Pivot vulnerability CVE-2022-21765 for arbitrary code execution in the Linux kernel on Mediatek’s older (“Helio”) chipsets, which use 32-bit kernels. I also mentioned that using previous ideas, the vulnerability could theoretically be exploited on Mediatek’s newest chipset family (Dimensity, which uses 64-bit kernels) as well. After the conference, with my college Lorant Szabo we have completed this exercise. The vulnerabilities: CVE-2022-21765 and CVE-2022-21769 To recap, the vulnerabilities provide an OOB read/write in the Linux kernel driver that implements the Application (AP) and Cellular Processor (CP) interface, which Mediatek calls the CCCI driver.

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.

Last year we published UnZiploc, our research into Huawei’s OTA update implementation. Back then, we have successfully identified logic vulnerabilities in the implementation of the Huawei recovery image that allowed root privilege code execution to be achieved by remote or local attackers. After Huawei fixed the vulnerabilities we have reported, we decided to take a second look at the new and improved recovery mode update process. This time, we managed to identify a new vulnerability in a proprietary mode called “SD-Update”, which can once again be used to achieve arbitrary code execution in the recovery mode, enabling unauthentic firmware updates, firmware downgrades to a known vulnerable version or other system modifications.

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.

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