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.

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.

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.