Apple fans, Android world scramble to patch Broadcom's nasty drive-by Wi-Fi security hole
Grab firmware updates ASAP
Yesterday, Apple rushed out an emergency patch to plug a severe security hole that can be exploited to wirelessly and silently commandeer iPhones, iPads and iPods.
Now we know why: this remote-code execution vulnerability lies in Broadcom's Wi-Fi stack, which Apple uses in its handhelds. Many other handsets and Wi-Fi routers also use Broadcom's naff HardMAC chipset, and, as a result, we expect – and hope – a lot of other phone, tablet and gateway makers push out patches: any gadget using Broadcom's vulnerable tech is at risk to over-the-air hijacking, not just Apple's iThings.
Here's a summary of the work by Google Project Zero's Gal Beniamini: the firmware running on Broadcom's wireless system-on-chip (SoC) can be tricked into overrunning its stack buffers. He was able to send carefully crafted wireless frames, with abnormal values in the metadata, to the Wi-Fi controller to overflow the firmware's stack, and combine this with the chipset's frequent timer firings to gradually overwrite specific chunks of device RAM until arbitrary code is executed.
In other words, an attacker simply needs to be within Wi-Fi range to silently take over an at-risk Apple or Android device: the hacker has to be on the same wireless network as the victim's device, or they can set up an open access point to lure a mark's handheld onto their own network.
Beniamini today detailed his research in this epic 8,500-word blog post.
What he found is that Broadcom's "firmware implementation ... lags behind in terms of security. Specifically, it lacks all basic exploit mitigations – including stack cookies, safe unlinking and access permission protection."
Android devices that use Broadcom's crappy SoC software include the Nexus 5, 6 and 6P, and most Samsung flagship devices, plus all iPhones since the iPhone 4 and newer iPods and iPads: these will all need patching as soon as updates are available. The Android April 2017 security update should include the necessary fixes, so keep an eye out for it. The proof-of-concept exploit detailed in the blog post was successfully performed on a Nexus 6P running Android 7.1.1 version NUF26K, which was the latest available at the time of testing in February.
Project Zero didn't go to work as a hit job on Broadcom, Beniamini says. Rather, most vulnerability research focuses on application processors. Peripherals like Broadcom's Wi-Fi SoC don't get the same degree of scrutiny, and Broadcom is the nine-hundred-pound gorilla in the business.
Only the beginning: the Wi-Fi SoC is just one attack surface in a smartphone
After a lot of work to extract and analyse the chip's firmware – the blog post thanks various peeps for their assistance – and identify the Wi-Fi handling code in the binary image, Beniamini settled on Broadcom's implementation of tunneled direct link setup (TDLS).
Published as a standard in 2011 and given Wi-Fi Alliance certification in 2012, TDLS lets devices exchange data as peers, without passing data through an access point, as long as they're both associated with the same access point – for example, to send video from a phone to a Chromecast without clogging up the rest of the network.
TDLS has two characteristics that make it an attractive attack vector:
- It's an automatic process that doesn't demand user interaction.
- Because it's a peer-to-peer process, an attacker doesn't have to route packets through an access point to get to the victim.
It turned out that TDLS frames had fields that could cause the firmware to overrun its buffers. "Putting it all together we can now hijack a code chunk to store our shellcode, then hijack a timer to point it at our stored shellcode. Once the timer expires, our code will be executed on the firmware," Beniamini explained.
Beniamini has promised a followup post explaining how to escalate the injected code from running on the SoC to running on the main application processor.
Broadcom said its latest firmware now uses the Wi-Fi SoC's ARM Cortex R4 core's builtin memory protection mechanisms to prevent code running from the stack. These mechanisms were effectively disabled on the versions probed by Beniamini, and all memory was marked as readable, writeable and executable, rendering exploitation easy peasy.
Broadcom added that it is "considering implementing exploit mitigations in future firmware versions." ®