This year, at DEF CON 28 DEF CON Safe Mode, security researchers [Jiska Classen] and [Francesco Gringoli] gave a talk about inter-chip privilege escalation using wireless coexistence mechanisms. The title is catchy, sure, but what exactly is this about?
To understand this security flaw, or group of security flaws, we first need to know what wireless coexistence mechanisms are. Modern devices can support cellular and non-cellular wireless communications standards at the same time (LTE, WiFi, Bluetooth). Given the desired miniaturization of our devices, the different subsystems that support these communication technologies must reside in very close physical proximity within the device (in-device coexistence). The resulting high level of reciprocal leakage can at times cause considerable interference.
There are several scenarios where interference can occur, the main ones are:
- Two radio systems occupy neighboring frequencies and carrier leakage occurs
- The harmonics of one transmitter fall on frequencies used by another system
- Two radio systems share the same frequencies
To tackle these kind of problems, manufacturers had to implement strategies so that the devices wireless chips can coexist (sometimes even sharing the same antenna) and reduce interference to a minimum. They are called coexistence mechanisms and enable high-performance communication on intersecting frequency bands and thus, they are essential to any modern mobile device. Despite open solutions exist, such as the Mobile Wireless Standards, the manufacturers usually implement proprietary solutions.
Spectra
Spectra is a new attack class demonstrated in this DEF CON talk, which is focused on Broadcom and Cypress WiFi/Bluetooth combo chips. On a combo chip, WiFi and Bluetooth run on separate processing cores and coexistence information is directly exchanged between cores using the Serial Enhanced Coexistence Interface (SECI) and does not go through the underlying operating system.
Spectra class attacks exploit flaws in the interfaces between wireless cores in which one core can achieve denial of service (DoS), information disclosure and even code execution on another core. The reasoning here is, from an attacker perspective, to leverage a Bluetooth subsystem remote code execution (RCE) to perform WiFi RCE and maybe even LTE RCE. Keep in mind that this remote code execution is happening in these CPU core subsystems, and so can be completely invisible to the main device CPU and OS.
Join me below where the talk is embedded and where I will also dig into the denial of service, information disclosure, and code execution topics of the Spectra attack.
Denial of Service
This happens when one wireless core denies transmission to the other core. DoS attacks are possible if one core is able to claim spectrum resources of the other core. As this is the basic working principle of any coexistence interface, all of them are vulnerable by definition, as long as one core keeps constantly claiming the resource for himself. Other DoS opportunities arise from one wireless core being able to crash another via shared RAM abuse.
Information Disclosure
One wireless core can infer data or actions of the other core. One example is when connecting an HID device like a keyboard. Timings and contents of keypresses can be observed on the host that receives those keystrokes. However, an attacker who has only code execution on a WiFi chip should not be able to make such observations. While the content of the keypresses are missing, it is possible for code running on the WiFi chip to infer timing statistics about the keys pressed in the Bluetooth side. This becomes interesting for inferring passwords and password lengths.
Code Execution
One wireless core can execute code within the other core. The security researchers demonstrate that it is possible to execute an arbitrary WiFi address with controlled contents via Bluetooth. This happens because when both cores are running, they share a RAM region which contain, among other information, a large function table. By overwriting a specific address, it is possible to control the WiFi core program counter. This means that a Bluetooth subsystem exploit can turn into a WiFi exploit. In addition, writing to the WiFi buffer and executing addresses produces various kernel panics on Android and iOS, indicating that further escalations into the host are possible and probably it’s just a matter of time until someone pops calc.
Conclusion
Although the research was centered on Broadcom and Cypress combo chips (which cover, by the way, all iPhones, MacBooks, iMacs, older Apple Watches, Samsung S and Note series, some Google Nexus, Raspberry Pi and so forth…) advisories were sent to Intel, MediaTek, Qualcomm, Texas Instruments, Marvell, NXP and they all mention similar coexistence interfaces in their devices. So, mutatis mutandis, and because of its very nature, some Spectra class vulnerabilities probably exist in other vendors too.
And since [Jiska] has a history breaking wireless stuff, we can probably expect a follow-up on this research and this class of inter-chip privilege escalation vulnerabilities. Can’t wait!
Good work.
Can’t say I am surprised… Little surprised at some of the shared resources and methods in these chips, having never looked at how these chips work before.. But much like the Intel ME risk, and all the recent side channel vulnerabilities any time you have shared resources you at the minimum have some capability to infer what other processes are doing. Something that can’t really be prevented just obscured and kept to a level where the inferable information is relatively harmless.
And in the case of something like this (or the ME) its quite possible for it be co-opted and yet work normally as its a standalone device so there is no monitoring from the host system no obvious sign anything is wrong.
Nice work, but privilege escalation seems to be a prerequisite. I’ll have to file this under all the other interesting things that are possible if you already own the system.
slowly we shall realise, that our computers are made of another set of computers. the things we refer to as ‘devices’ are just a bunch of CPUs of different kind, running code. when there’s a lot of scrutiny on the security of the ‘topmost’ OS, the things are quite similar one or even two layer below. sure, it is harder to reach to those points if the OS does a great job, but as we see, there are other ways. people who write code, also make errors. once Theo de Raadt made a really true comment about virtualisation as a security measure:
“You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can’t write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.”
i guess, the same applies to those firmwares running in our devices.
That’s the big problem with cryptocurrency. If by bank details get hacked, the transactions can be reversed, and the hacker sent to jail.
CC has no reversal mechanism, and some are even totally anonymous and perfect for theft.
All current tech seems to have the assumption that 1 in a few thousand chance of getting hacked is enough security for consumer devices. Which is fine with me, because we try to also design everything else to be recoverable in that case. With Bitcoin we’d need either dedicated devices, or to start making some major sacrifices for security.
Unfortunately, in this territory, our primary security is not the statistical probability of successful intrusion into a device, but the statistical probability of a potential intruder to be caught after going into a device (which is heavily determined by the negative monetary effect of said intrusion). Of course the ease of intrusion is a factor in both of those scenarios, but only a factor. Without any of ours’ being able to even access the internet with certain anonymity, then all of us are guaranteed a certain level of consequence-security–a decision that seems to have been made for us…