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.
I think this has pushed me over the edge.
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?
The issue likely exists in a limited number of chips, possibly only FullMAC ones, like similar bug found earlier by Google:
Actually NIST lists the vulnerable NICs: BCM4354, BCM4358, BCM4359.
 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.
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.
$ lspci | grep -i BCM43
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.
Can anyone see a reason this wouldn't work?
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.
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.
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.
The Broadpwn discoveries were informed by the techniques used by PZ to discover the original exploit.
If you are the adventurous type, this comment has links to the blog post which has a PoC.