Systems-on-a-chip are a huge, unaudited attack surface, says Project Zero's Wi‑Fi attack man

The internal inter-chip communications of devices like smartphones are a “huge, mostly unaudited attack surface,” according to Gal Beniamini of Google’s Project Zero, in his promised follow-up to last week’s demonstration of how to attack Wi‑Fi chips over the air.

His April 4 “part one” prompted emergency patches from Apple and Google, new drivers from Broadcom and a lot of scratched heads about which other devices use the FullMAC system-on-chip (SoC) devices.

Beniamini calls for better memory isolation between SoCs and the host processors, along with exploit mitigations like stack cookies, to protect devices against Wi‑Fi-borne attacks.

Beniamini’s first post only got as far as remote code execution on the Wi‑Fi chip itself, but at the time he said there are paths from the SoC up to the application processor. He's now detailed those issues in 8,300 words of gory detail here.

If you don’t have much time, Beniamini found both low-level (the easy way) and high-level (the hard way) communication paths that made the application processor attackable:

• The “easy way” is to attack the communications channel that links the SoC to the application processor.
• The “hard way” is to attack high-level messages the SoC passes to signal important Wi‑Fi events to the host (such as SSID discovery, Wi‑Fi power level and so on).

The Register is going to take the liberty of detailing the “easy way” first, reversing the order of Beniamini’s post.

"The utilisation of hardware components remains as it is, and is currently not mitigated against."

The link from the SoC to the host

SoCs support a bunch of different upstream interfaces – Beniamini lists the mostly obsolete SDIO along with USB and PCIe. PCIe is the fastest, it uses DMA (direct memory access) to talk to the processor, and since it’s becoming the default in modern devices, that’s the one Beniamini chose to attack.

After a fair bit of stack trace work to untangle the communication protocols the Broadcom SoC uses to talk to the host, he found a spot where the SoC “managed to DMA into the physical address range containing the host’s kernel, without any interference” (among other things indicating either a lack of a system memory mapping unit or a configuration error).

Broadcom’s SoftMAC driver brcmsmac revealed to the researchers how to map out the SoC’s DMA access and identify which structures represent host-to-device and device-to-host accesses.

That provided a path to “hijack any kernel function with our own crafted data” – in other words, complete pwnage of the kernel.

The hard way

Beniamini’s “hard way,” actually his first line of research, was to look at how the SoC signals things like “SSID available” or Wi‑Fi power level to the host.

What he found is that such control messages all use the same EtherType, 0x886C, which encapsulates “information about firmware events which must be handled by the host’s driver.”

0x886C frames were unfiltered until last May, but there are two problems with this: if you pwn the SoC, you can revert that patch; and the WLC_E_PFN_SWC event that signals “significant Wi‑Fi change” (one of 144 possible, of which the Broadcom Android driver supports 35 – a genuinely huge attack surface) is still attackable.

Android’s April bulletin fixed five such holes that Beniamini discovered during his research.

The WLC_E_PFN_SWC work revealed an unchecked, untrusted array, meaning “an attacker with the ability to inject arbitrary event frames can specify a small total_count and a larger pkt_count, thereby triggering a simple kernel heap overflow.”

The reason Beniamini set aside this line of work is that while the vulnerability is genuine, it would have been “tedious” to write a reliable exploit (he should know, given the amount of work needed to get through to a kernel crash).

Beniamini’s how-to for pwning the Wi‑Fi processor is here, and our summary is here. ®