Live data from Hacker News

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

blog.exodusintel.com

151–160 of 171 posts

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

#151
post #46
post #10

Earlier quoted context omitted.

This page has a table of OEMs/devices that, as of the end of May, were fewer than 60 days behind on patches. https://android-developers.googleblog.com/2017/06/2017-andro... To me, the takeaway from this is that unless you are using a "flagship" device, or one sold directly by Google, you're probably not getting updates in a timely manner.

And yet another time we learn why it is better to use Lineage OS. Five year old Samsung S3: Android: Version 7.1.2 Security Patch Level: 5th July 2017

Note that not all vulnerabilities are/can be patched by LineageOS, regardless of what the security patch level claims. Your device maintainer needs to actively merge patches into the kernel/device (see [0], note that this list relies on maintainers to update it). In addition, binary blob firmware needs to be patched by the manufacturer (e.g. Broadcom wi-fi exploits), which won't happen for devices that are out of support.

[0] https://cve.lineageos.org/kernels

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

#152

Earlier quoted context omitted.

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.

Is their firmware really noticeably better or have more features than competing chipsets?

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

#153

Earlier quoted context omitted.

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.

Is their firmware really noticeably better or have more features than competing chipsets?

Yes. 802.11ac, for example, takes both a faster transceiver and a bunch of firmware support, and time to market with this features was a big driver of sales. And that was an ongoing process - ac is actually a set of features, and it's taking years for all of them to be implemented.

Similarly, cheaper chips often don't support optional performance-enhancing features at layers 2 and 3 (link and MAC) that boost performance without any hardware investment.

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

#154

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.

There's a reason "THIS SIDE TOWARDS ENEMY" is a thing.

It's actually

       FRONT

    TOWARD ENEMY
[1] https://en.wikipedia.org/wiki/M18_Claymore_mine

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

#155
Apple pushed out an update to ALL affected iOS devices last week. Google provided patch for nexus and pixel devices. Vast majority of android devices (think close to 99%) are still vulnerable.

Given how limited pixel availability is and how quickly support is dropped compared to Apple, the logical recommendation is to drop android and switch to iPhones immediately.

Bring the downvotes but at least provide logical discussion.

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

#156

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.

There is no benefit. They probably have an embarrassing code base that is full of garbage and a bunch of lawyers paranoid about IP. Why would any manager suggest to take that risk that has very little potential upside. It isn't that it would be realistically detrimental, it just has no value to the individual attempting to change the established course of the ship

Judging from what I've seen of their drivers, yeah, their firmware/microcode is probably an embarrassing bug-ridden code base. But it also represents a lot of investment in low-level/low-layer features that they would prefer to hide from competitors (much more sensitive than the higher-layer logic in the driver proper).

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

#157

Earlier quoted context omitted.

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.

The other hugely important side of this is that a lot of these devices have the ability to transmit on frequencies which they may not be licensed for, or may not be licensed for in all markets.

The easiest example being b/g channel 13. You're permitted to use it for WiFi in most of the world, but not North America. Keeping the firmware proprietary and "secure" is likely an important part of their FCC/IC certifications.

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

#158

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.

1. Why doesn't Apple open source iOS?

2. These weren't drivers. Did you read the article?

3. The larger share of the blame belongs to Apple. Why does Apple trust devices like this that are essentially independent computers? Why should anything this chip does be able to take over the phone and install software on it, in privileged mode, that replicates itself?

4. Why can't you see things rationally?

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

#159
post #14

C's lack of array size info strikes again: memcpy(current_wmm_ie, ie->data, ie->len); where "ie" points to data obtained from the net.

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.

It's 2017. It's about time we had a better, well designed language (ie Rust, but I'm not sure if it's well designed enough, depends on what you want it for, too). There have been many advances in language research since the 70's that could be very useful for the kind of work C is used for. Saying we should stick to C because it's well established is like saying we should stick to assembly if it was well established. Except it's not portable, but close enough.

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

#160
post #126

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

Why are you waiting to update?
Post reply on HN