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

121–130 of 171 posts

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

#121

Post by pmontra »

armitron wrote: post #53
pmontra wrote: post #32

Earlier quoted context omitted.

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.

High level != Superset

Actually we often give up features and specialize with high level languages. That's why there are things easier to do in Ruby than in C++ and vice versa.

They are all (usually much more convenient) subsets of assembly.

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

#122

Post by samat »

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.

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

#123

Post by swerner »

Fortunately, this is being addressed in software updates. Unfortunately, people who own older devices are left with the vulnerability forever. The iPhone 4S alone sold ~60 million units (according to Wikipedia) and did not (and most likely will not) receive any updates.

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

#124

Post by nl »

mmjaa wrote: post #120
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.

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

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

#126

Post by yojex »

swerner wrote: post #123

Fortunately, this is being addressed in software updates. Unfortunately, people who own older devices are left with the vulnerability forever. The iPhone 4S alone sold ~60 million units (according to Wikipedia) and did not (and most likely will not) receive any updates.

Where can you learn if your device has been patched? I have an iPhone 5S.

EDIT: From another comment [0], unfortunately if you've been holding out on updates like I have you'll have to upgrade to 10.3.3.

[0] https://support.apple.com/en-us/HT207923

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

#127

Post by FungalRaincloud »

mmjaa wrote: post #120
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.

>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?

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

#128

Post by zeristor »

yojex wrote: post #126
swerner wrote: post #123

Fortunately, this is being addressed in software updates. Unfortunately, people who own older devices are left with the vulnerability forever. The iPhone 4S alone sold ~60 million units (according to Wikipedia) and did not (and most likely will not) receive any updates.

Where can you learn if your device has been patched? I have an iPhone 5S. EDIT: From another comment [0], unfortunately if you've been holding out on updates like I have you'll have to upgrade to 10.3.3. [0] https://support.apple.com/en-us/HT207923

From this it seems to have been a applied in last week's iOS patch, 10.3.3

https://9to5mac.com/2017/07/20/broadpwn-wifi-vulnerability-i...

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

#129

Post by moocowtruck »

orf wrote: post #45
corndoge wrote: post #33

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…

Tools exist that find this error in C code, more to blame the company that didn't use those tools and released code this important. Blaming the language solely... not sure it's productive. If the gun went off in my holster WITH the safety on then I'd blame the manufacturer. Same goes with using the right tools with C, if all steps were taken to do the right thing then I can say we should blame C. But there's not any information here on how broadcom developers their code internally.

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

#130

Post by ethbro »

axaxs wrote: post #111
Canada wrote: post #109

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.

> 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 going to follow a more informed curve.

The gatekeepers (manufacturers) are the only ones informed enough to make the decision en mass. And they're not going to do so without a market reason. So barring something like "Broadcom stops providing security updates" or "New law holds device manufacturers liable for security bugs" they're going to save the few cents on BoM and continue using them.

Post reply on HN