111–120 of 171 posts
Earlier quoted context omitted.
There are tons of benefits, to the end users. But most of them result in the user having less reason to buy a new device in the hopes of faster or more reliable WiFi.
End users don't really matter to Broadcom. Chip makers don't sell product to end users, they sell to device manufacturers.
Earlier quoted context omitted.
End users don't really matter to Broadcom. Chip makers don't sell product to end users, they sell to device manufacturers.
absolutely true. But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception.
Manufacturers currently have no choice but to ship devices running vulnerable application software that communicates with remote devices using vulnerable protocols. This is facilitated by vulnerable operating systems running many vulnerable device drivers communicate with devices that themselves have embedded processors running yet more vulnerable software.
All manufacturers can do is keep patching the morass of code that their offering depends on, but most device manufactures can't even manage that, or if they can they are unable do it fast enough and unwilling to do it for long enough.
Earlier quoted context omitted.
If you have an iPhone make sure you're on iOS 10.3.3. For Macs, you want macOS 10.12.6.
Why is El Capitan not getting an update? It's still on support.
Earlier quoted context omitted.
which basically means don't use any wifi. I think at least 60% of all wi-fi chipsets are broadcom ones.
that seems pretty doable. on phones there's qualcomm chipsets, and on desktops/laptops there's atheros, intel, and realtek (of the vendors i know of).
Earlier quoted context omitted.
They intercept and modify packets to redirect to a web site they control. It exploits the main processor through the browser.
Assuming one has additional browser vulnerabilities, sandbox escapes and privilege escalation bugs. "Broadpwn" doesn't exploit main processor __anything__ by itself.
Earlier quoted context omitted.
Programmer's mistake for not validating data, not the fault of C language mechanics. Yes it would be easier if , still gotta be careful. I've made plenty of these mistakes but never blamed the language.
If a manufacturer makes and sells a gun that keeps going off in people's holsters and shooting people in the foot, the answer is not to say "it's the user's fault for not using it properly. I've shot myself in the foot hundreds of times and I don't blame the manufacturer". Or something. That analogy sounded better in my head than written down. The point is that IMO the blame lies squarely with the C language: it's a…
Probably, because it's really bad.
Earlier quoted context omitted.
One theory I've seen bandied about related to GPU drivers is that it's harder for your competitors to notice you're infringing on their patents if you don't ship your source code.
This seems unlikely. (Or maybe that's the reason given, but it seems implausible to be true.) Competitors have more than enough know how to determine if you're infringing a patent, source or no source.
Reverse engineering silicon to figure out if you used a specific type of patented algorithm is super hard.
Looking at open source code is waaaay easier.
Earlier quoted context omitted.
The drivers are probably pretty complicated and thus valuable IP.
I don't buy that. Every wifi chipset has working drivers; therefore there is little to no value in Broadcom's driver as "IP". Contrast that to the value of having a free driver that can receive security patches from anyone at any time .
Competitors could review the code and "copy" how great features work without actually copying the code.
Earlier quoted context omitted.
Assuming one has additional browser vulnerabilities, sandbox escapes and privilege escalation bugs. "Broadpwn" doesn't exploit main processor __anything__ by itself.
Does the broadcom processor normally have access to main memory? If so, I would have to consider that a complete attack absent any mitigation technology.
Why does Broadcom insist on proprietary drivers? How could it possibly be detrimental for Broadcom to have free software drivers? This article is a poignant example that it is detrimental for them to continue to keep their drivers proprietary.
Because they are used as a front/vector for US intelligence agencies. Opening this firmware would not allow for the distribution of these implants.