Broadcom BCM43xx Wi-Fi chips allow remote attackers to execute arbitrary code | Hacker News Reader

Broadcom BCM43xx Wi-Fi chips allow remote attackers to execute arbitrary code

nvd.nist.gov

220 pointsrnhmjoj42 comments

More info is available here:

http://boosterok.com/blog/broadpwn/ http://boosterok.com/blog/broadpwn2/

Previous discussion: https://news.ycombinator.com/item?id=14727400

I've got a Macbook Pro from 2011 with BCM4331. So there must be a metric f ton of hardware affected.

The firmware is embedded in the closed source drivers, it's not available separately. It's uncertain how far back Broadcom will update their driver packages.

On Linux if you want to use the open source driver, either the distro or user must extract the firmware from the closed source driver using b43-fwcutter. I don't know what the license restrictions are that apply to distros that appear to include it in the base installs, and therefore probably get updated. But distros like Fedora don't include it due to license restrictions. Therefore it won't get updated automatically.

I think the kernel driver should warn, if not refuse to use without a force option, on firmware versions below a certain value.

Note that Cypress acquired these from Broadcom and have opened up a lot of the documentation. There's still quite a lot of info not present, and they might still be going through and renaming them, but maybe if you ask... either way, a surprisingly pleasing result in contrast to the notoriously closed attitude before.

It feels like we just had another massive wifi firmware exploit not too long ago. iOS 10.3.1 / CVE-2017-6975 / CVE-2017-6956 / https://bugs.chromium.org/p/project-zero/issues/detail?id=10...

This is because these things are full of bugs, previously it's just been fewer people looking.

Love my macbook pro (linux), but the broadcom chips are such a pain. Almost enough me to drop Apple hardware.

I think this has pushed me over the edge.

What Wi-Fi chip vendor would be preferable then?

Broadcom's Wi-Fi chip solution has now been the focus of many man-months of security analysis, but I'm not aware of any other vendor that has seen the same thorough analysis, or?

Is any Wi-Fi chip vendor actively marketing themselves as security oriented and has anything to show to back that up?

Have you actually read the CVE and articles? This is not Apple-specific at all...

I think he's just saying that broadcom is the only option with macbooks.

No, but Apple uses a lot of Broadcom chips

I agree. I have an older Macbook Pro from 2010 and none of the Linux drivers, b43 or Broadcom's wl, can get anything better than 17Mbps to my access point. If I boot from Mac OS, I get 70Mbps. They also can't do 4-addr bridging and are missing some other features. Add to that all of the ACPI problems and it makes for a very poor Linux experience.

So since this is in the firmware is it safe to assume that this affects all devices with the broadcom chip, regardless of what OS they're running?

Probably not all BCM43xx devices are affected, though. This product line spans over 10 years and all 802.11 revisions since a/b with various firmwares and internal CPUs, from custom cores to ARM.

The issue likely exists in a limited number of chips, possibly only FullMAC ones, like similar bug found earlier by Google:

https://googleprojectzero.blogspot.com/2017/04/over-air-expl...

edit:

Actually NIST lists the vulnerable NICs: BCM4354, BCM4358, BCM4359.

NIST's list is incomplete, at least BCM43570 is vulnerable as well [1]. I would expect many more Broadcom chips to be vulnerable even if exploits may need to be tweaked.

[1] I'm part of a team that develops a product with this chip, and I've used the hostapd configuration I linked elsewhere in this topic to show it is vulnerable.

Mostly. If this is the same thing that was posted in the last month or so, then it's possible for it be patched. Whether it's the firmware itself or through a mitigation technique in the OS, I can't remember. The last time it was posted, it was mostly about phones, and there was an update for Android phones that "fixed" the bug. The status of the bug on iOS was unknown.

It may be that the bug is easily defendable against at the OS level if one knows that it could be present.

Edit: Somebody else posted the previous discussion, so I think it's the bug I'm thinking of.

In general the firmware for these devices is loaded by the OS at startup, so the OS simply patches the firmware file. Checking the linux-firmware tree for what I presume to be the same devices, though, I see a few recent commits to a handful of files, but nothing that looks like it might be a fix to this issue:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

Does this affect laptops running Linux? How do you know if you are vurnurable?

This should show if you have a BCM43xxx device:

$ lspci | grep -i BCM43

If you have broadcom wifi, then probably you are

googling for solutions/patches/fixes for ubuntu don't seem to yield much (though that doesn't give me much confidence). I wonder if it's just drowning in the noise about android/ios

You would expect to see it first here: http://lists.infradead.org/pipermail/b43-dev/

The b43 devs would be the ones to add new firmware. I don't see any activity around this CVE there, however.

Probably the right place to ask though.

Linux laptops should be fine--no one can ever get Broadcom working on Linux anyway.

Seems to be fixed in Android July security update. Not sure wrt iPhone, iPad.

I hope someone will write a very visible worm that spreads via unpatched Android phones (approximately all of them) and finally forces Google to take updates seriously.

Can anyone see a reason this wouldn't work?

The fact tha Google is pretty timely with updates, and if this happened the manufacturers would be content with letting the malware push people towards earlier upgrades?

What do you hope such an attack would achieve? Giving Apple more market share?

Apple controls the iPhone soup to nuts and can update them as they see fit. They are the OEM and they do not allow Carriers to modify their devices.

Google provides an OS for free and stipulates that OEMs must make some concessions to get the GAPPs everyone wants for that OS. It has no where near the control over handsets or the ability to update them without cooperation from OEMs and Carriers who contracted with those OEMs.

With each new version of Android, Google is asking for more and more control over the system however they'll never own the devices or be able to exert their will the way Apple can.

Attacking field devices won't spur Google to ship magic updates to everyone's unsupported handsets because they couldn't even if they wanted to. It might spur them to make additional changes in future OS versions but the vast majority of handsets in the field would never receive those updates.

I'd hope that it pushes Google to rearchitect Android so that updates can actually be installed by the vast majority of people. Before saying "but that's impossible, it's down to the OEMs!" consider:

1. Windows runs on many many PCs and it is trivial to keep updated, so it is possible without OEM cooperation.

2. Google actually have finally started this work, which proves that they can solve, or at least improve the situation. But the fact that they didn't start working on it until now shows how low a priority it is for them. That is what needs to change, and I would hope an automatic Wi-Fi worm would do it.

You realize that Google doesn't distribute OS binaries to OEM's, correct? So why are you using Windows as an example? Each OEM downloads the Android OS source, adds their modifications and builds their own OS. How is Google supposed to modify or update an OS not built by them?

Fortunately, your dream will never come true. Remember Stagefright? Whatever happened to that? Oh, that's right nothing ever happened. There hasn't been one reported case of Stagefright in the wild according to Google's telemetry of over 2 Billion Android devices that use GMS.

Finding an exploit is one thing, making it work and bypassing all of the OS mitigations, on a platform that essentially has OEM's build their own OS, is an entirely different matter. It's why Stagefright never got anywhere and it's also why this will go the same way Stagefright did.

It was fixed in ios 10.3.1 (3rd April) https://support.apple.com/en-us/HT207688

Is that the same bug, or a different one, though?

It's a different bug. 10.3.1 patches this bug, which isn't Broadpwn

https://googleprojectzero.blogspot.com/2017/04/over-air-expl...

The Broadpwn discoveries were informed by the techniques used by PZ to discover the original exploit.

Was at Blackhat https://www.blackhat.com/us-17/briefings.html#broadpwn-

by @nitayart

Will be at blackhat ;-) July 22 is not today ...

Are there any tools out yet, to patch and check if your vulnerable?

Best way is to google your phone model and see if it is in the list of affected devices list. Or you can get the chip's details by prodding with the adb shell.

If you are the adventurous type, this[1] comment has links to the blog post which has a PoC.

[1]:https://news.ycombinator.com/item?id=14776192

One device specification resource:

http://www.devicespecifications.com/

I haven't looked into how the exploit works in detail, but could this affect the RaspberryPi 3?

No. Same company, completely different products.

Ah interesting, doesn't the Pi 3 use the same wifi chipset though? I think the Pi uses BCM43438. I'm not sure if all 43x chips use the same firmware.

I think it's a difference between the firmwares that like the b43 driver uses, and the ones that the brcmfmac driver uses. I've got a laptop with a bcm4312, and it's got a very different-looking set of firmware files than the ones used in my Pi3.

Reply on news.ycombinator.com