Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.exodusintel.com

Post reply on HN
Print view View original

141–150 of 171 posts

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

#141

Post by mmjaa »

FungalRaincloud wrote: post #127
mmjaa wrote: post #120

Earlier quoted context omitted.

>How could it possibly be detrimental for Broadcom to have free software drivers? Because they are used as a front/vector for US intelligence agencies. Opening this firmware would not allow for the distribution of these implants.

While I acknowledge that this is a very real possibility, I don't think it has anything to do with the motivation to keep the source closed. I think more to do with an old world mentality that all intellectual property is a trade secret. Why share, when there's no real penalty to not sharing?

The question is, what value is secrecy, and alas the answer is that for those who want to exploit their technology prowess over others, secrets are a dire necessity.

An open ideology is one where everyone wins, even those who aren't on your team. The closed one is mostly to protect ones own team. I don't consider any of the reasons to be good reasons, personally. Commercially necessary, perhaps, as a conforming act as part of the "super-state", also perhaps.. but nevertheless, the best conclusion is that this situation is rotten enough to motivate someone to fix it.

Me personally .. I'd love to have the sources for every sub-processor/component in my system. It would be of immense value - commercially and otherwise - to me as an end-user. I hope I don't sit alone in this market...

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

#142

Post by mmjaa »

nl wrote: post #124
mmjaa wrote: post #120

Earlier quoted context omitted.

>How could it possibly be detrimental for Broadcom to have free software drivers? Because they are used as a front/vector for US intelligence agencies. Opening this firmware would not allow for the distribution of these implants.

Well based on the number of NSA and CIA "implants" in Linux and other open source software it isn't clear that makes a lot of difference.

It is indeed a battle.

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

#143

Post by azernik »

whowouldathunk wrote: post #19
thomastjeffery wrote: post #18

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.

The drivers are probably pretty complicated and thus valuable IP.

Having worked on enterprise APs using BCM and Atheros chipsets:

The driver is not deeply protected IP. They will hand out full copies to any device manufacturer that uses they're chipset, so that they can integrate it with their systems. The secret sauce, the bit that they won't share with anyone even if it's necessary for debugging, is the on-chip firmware. That's the stuff they take seriously. The driver itself is just a lawyer thing.

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

#144

Post by azernik »

thomastjeffery wrote: post #18

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.

The bugs in question here are not in the drivers (the bits that run in the OS kernel on the CPU). They are in the firmware (code that runs on a little ARM core on the WiFi chip itself - also called the microcode in the biz).

The driver is indeed "protected" for IP-lawyer reasons; they'll have it out under license to every Tom, Dick, and Jane looking to build a device with their chipset. The firmware, on the other hand, is very closely held, because that's where the chip's functionality lives. A WiFi chipset implements a fantastically complicated protocol, and no one wants to bake that into hardware that can't be updated as bugs are found; so they build relatively simple hardware, and slap a microcontroller right on the die that runs all the complicated logic.

This means that the microcode is as sensitive as The hardware specs on earlier generations of hardware; a competitor with a copy of that source can make a (perhaps better and improved) knockoff if they're not too worried about legal implications like, say, several dozen Chinese knockoff shops.

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

#145

Post by thomastjeffery »

azernik wrote: post #144
thomastjeffery wrote: post #18

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.

The bugs in question here are not in the drivers (the bits that run in the OS kernel on the CPU). They are in the firmware (code that runs on a little ARM core on the WiFi chip itself - also called the microcode in the biz). The driver is indeed "protected" for IP-lawyer reasons; they'll have it out under license to every Tom, Dick, and Jane looking to build a device with their chipset. The firmware, on the other han…

    echo $original_comment | sed 's/driver/firmware/g'

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

#146

Post by azernik »

yifanlu wrote: post #38
ktRolster wrote: post #25

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

> Broadpwn is a fully remote attack against Broadcom’s BCM43xx family of WiFi chipsets, which allows for code execution on the main application processor in both Android and iOS. This implies they have code execution on the application processor just from broadpwn (and not additional safari/ios exploits). Hijacking internet traffic is indeed serious but tech blog sites are already picking up on this and blowing it up…

Probably because a device on the system itself has tremendous privileges; aside from interacting with non-hardened kernel code (drivers generally trust the device but to be malicious), they generally have DMA access, in PCI can impersonate the CPU when speaking to other devices, and can generally cause all kinds of havoc.

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

#147

Post by azernik »

dewyatt wrote: post #134
samat wrote: post #122

Could please someone explain, 1) if firmware is stored on a Wifi chip or rather loaded during the boot process? 2) Do apple/google have binary image from Broadcom or rather source code? It is quite interesting how this patch production/delivery process works.

> 1) if firmware is stored on a Wifi chip or rather loaded during the boot process? Typically it's loaded during the boot process. On Linux, see the binary blobs in /usr/lib/firmware or: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... Source: I did some work with some broadcom (wired) firmware years ago and found it to be pretty unpleasant. http://ipxe.org/gsoc/bnx2 and https://github.com/dewyatt/bnx2…

I worked with both QCA and Broadcom wireless, and can confirm. Generally a version of the driver is compatible with only a specific version of the firmware; the system manufacturer gets the driver source and a firmware binary as a package.

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

#148

Post by [deleted] »

thomastjeffery wrote: post #145
azernik wrote: post #144

Earlier quoted context omitted.

The bugs in question here are not in the drivers (the bits that run in the OS kernel on the CPU). They are in the firmware (code that runs on a little ARM core on the WiFi chip itself - also called the microcode in the biz). The driver is indeed "protected" for IP-lawyer reasons; they'll have it out under license to every Tom, Dick, and Jane looking to build a device with their chipset. The firmware, on the other han…

echo $original_comment | sed 's/driver/firmware/g'

[deleted]

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

#149

Post by azernik »

thomastjeffery wrote: post #145
azernik wrote: post #144

Earlier quoted context omitted.

The bugs in question here are not in the drivers (the bits that run in the OS kernel on the CPU). They are in the firmware (code that runs on a little ARM core on the WiFi chip itself - also called the microcode in the biz). The driver is indeed "protected" for IP-lawyer reasons; they'll have it out under license to every Tom, Dick, and Jane looking to build a device with their chipset. The firmware, on the other han…

echo $original_comment | sed 's/driver/firmware/g'

In which case this is your answer; they're worried about knockoffs, because without the firmware logic their devices are simple commodities, ie don't really have strong differentiators from the competition.

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

#150

Post by ethbro »

axaxs wrote: post #133
ethbro wrote: post #130

Earlier quoted context omitted.

> But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception. How many of your non-professionally-technical friends could tell you the manufacturer of their WiFi chip? Is it on the box? Could they even tell you who Broadcom is? "Intel NIC" only recently became a very minor selling point in enthusiast desktop motherboards. I'm not holding out hope this is…

I agree, but these things go up the chain. Sure people won't say 'I wont buy broadcom', or 'i wont buy snapdragon.' But they will say 'I won't buy PhoneCoXYZ because they were in the news for being hacked.' Not after this necessarily, but after enough times, I think we'll see it.

I'd like to move more towards this. And the branding and identification is probably a big part of this. Pushing news to report the culpable parties by name. "Samsung / Google / Apple recently had a flaw in their {model} phone" vs "Another phone vulnerability" desensitization.
Post reply on HN