> ...or someone spends a bit of time with an AI to come up with a patch?
Based on the guy's slides [0], it seems like Broadcom has already released a fixed version. The slide numbered as 97 contains this part of what I assume is an email with Broadcom:
Thank you for your above-cited report. This report is based on Broadcom’s 18.1 SDK release.
Broadcom has known about this specific vulnerability for a long time; other external entities have also reported it to us. For several years, Broadcom has been offering its customers updated software that lacks this vulnerability.
In particular, the WPS implementation in this old software package (based on WPS Monitor) was obsoleted several years ago and replaced starting in 2018 by a new implementation based on HostAPD and WPA Supplicant.
The blog post makes it sound like there was no updated version, but the guy's email with Broadcom says otherwise. If we knew the name of the SDK, we could check the release notes and maybe get the truth. I gave up after like a minute of searching for the name, but perhaps others are more interested in the search than I am.
[0] <https://quentinkaiser.be/assets/qkaiser-broadcom-wps-hexacon...>
I probably need to adapt the wording then.
Broadcom released an insufficient patch in 2018, then they moved to hostapd in their SDK. So as an OEM you can get the support of Broadcom to move to a fixed revision.
The whole issue is not that Broadcom has a bug, everyone has, it’s that their communication did not make its way down the supply chain.
They said they notified OEMs but refused to share the content with me. So we don’t know whether it was a single line in a changelog or an actual security advisory.
Since every OEM is not keeping track of all vendor communications, a proper CVE would have alerted the OEMs to take action 8 years ago I think.
could you also mention which driver this is somewhere? I deduct it is the proprietary broadcom-driver, so only used in routers? Also what happens if you turn WPS off?
> I probably need to adapt the wording then.
Yeah. I'd recommend changing
to something like
It makes it clear that Broadcom supplied a fixed version that uses hostapd, rather than making it seem like vendors might have been required to do the migration to hostapd themselves.
Broadcom just makes the chip right? So customers in this sense would be the router OEMs like netgear who may not have distributed the new update to end devices.
> Broadcom just makes the chip right?
And -based on the email- the SDK used by folks who use that chip in hardware, yes.
So, yeah. The customers are the folks who build the hardware that uses that chip and the relevant parts of Broadcom's SDK as part of the software loaded into that hardware. Though it could totally be the ISP's fault for not testing and deploying updated firmware for affected CPE. There's not enough information to know exactly who is at fault, but it doesn't look like it's Broadcom.
Is Broadcom not obligated to issue a CVE for a legitimate vulnerability?
Since they wouldn't share the contents of their notification to their customers, we don't know how clearly those customers (router makers) were notified. But having a CVE and detection signatures would get this vuln into all the usual scanning and reporting channels, which is another route the customers might (should!) be paying attention to.
Also, I don't know how laws over there work, but there might be legal requirements to patch things once they're known, where "known" is probably defined by "has a CVE issued". So by refusing to issue one, Broadcom is blocking that process.
How is that blameless?
> Is Broadcom not obligated to issue a CVE for a legitimate vulnerability?
One would imagine that both what Broadcom is obligated to do and the definition of "legitimate vulnerability" depend on the contracts between Broadcom and its customers, as well as the relevant laws and regulations, no?
> How is that blameless?
I'm going to ignore your speculation about hypothetical legal requirements that neither of us currently know anything about.
We're here talking about faults in CPEs nearly a decade after Broadcom released a fix for those problems and announced the availability of the new SDK version its usual channels. Broadcom also _claimed_ that they notified affected OEMs. [0]
You may disagree, but I'd say that if you have an in-support product with field-upgradeable software, and you don't bother to check the release notes and support status of the software components you have loaded into that product at least once every year or so, then you're definitely to blame. This goes double if you've been notified by the vendor of a vulnerable component that it's vulnerable and there's a fix available.
[0] <https://news.ycombinator.com/item?id=50148720>