Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

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

What goes on when chip components chat? Nobody cares. But they should

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

 

Similar topics

Similar topics

Similar topics

TIP US OFF

Send us news


Other stories you might like