Live data from Hacker News

Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

blog.exodusintel.com

51–60 of 171 posts

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#51

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.

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.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#52

Earlier quoted context omitted.

Every GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.

The driver 'optimizations' in GPUs tend to boil down to hand written replacements for unoptimal/broken shaders and API call sequences on a per application basis. I expect a network card to not 'interpret' my traffic in a similar way.

As someone who spent a ton of time in this space(working with most mobile GPU vendors from Android E to L) you're talking about things just at the surface.

The way the drivers + backing architecture are built contains tons of IP and things that they would very much not want their competitors seeing.

Our team built our reputation and relationship on keeping that data separate and confidential despite working with just about every vendor out there.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#53
post #32

Earlier quoted context omitted.

What do you mean by C not having arrays?

They are a pointer and an offset with no validation of bounds. But that's OK: C is little more than a high level assembly.

I hate the term "high level assembly" when applied to C since it's loaded against assembly (in the sense of C as its superset) which is obviously not true.

C is full of undefined behavior, assembly is not.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#54

Earlier quoted context omitted.

Every GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.

The driver 'optimizations' in GPUs tend to boil down to hand written replacements for unoptimal/broken shaders and API call sequences on a per application basis. I expect a network card to not 'interpret' my traffic in a similar way.

Adding the double blind optimizations leading to absurdly complex drivers that tries to guess how user code tries to guess driver logic... maybe vulkan will help open source GPU drivers in the end.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#55
post #35

Earlier quoted context omitted.

They only hijacked the radio chip, they didn't escalate to the main processor. One way of attacking would be to intercept someone's internet traffic, and redirect them to a different site (ie, instead of going to Google, you go to get-hacked which looks just like Google).

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.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#56

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 .

Tell that to the Open and guys who have been dying for wifi drivers for years. They are definitely not all open. Furthermore, not nearly as many people are running alternative OSes on their phones as they are on other types of computers.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#57

Earlier quoted context omitted.

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 .

Every GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.

GPU drivers are very bug ridden and 3D apps can easily cause OS crashes. Apps are tested so they don't trigger those bugs. Witness all the complaint comments on webgl posts about machine crashes - and that's with a thick driver bug workaround layer in browsers.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#58
post #45

Earlier quoted context omitted.

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…

I shot myself in the foot yet I don't blame the manufacturer for not putting a safety on the gun since I'm the one that bought it with full knowledge of the caveats

That doesn't mean that gun is well designed or worth buying and using. Criticising the lack of such a valuable or even essential feature and advising people not to use it would be fair comment. Right?

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#59
post #43
post #8

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).

So your considered recommendation is for 60% of recently bought device owners globally to all replace their phones, tablets and laptops with devices containing Qualcomm chips, immediately.

And this is preferable to a software fix.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#60

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.

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.
Post reply on HN