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

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

#91

Post by wtallis » Thu, Jul 27, 2017, 2:55 AM UTC

paulie_a wrote: post #82

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.

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

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.

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

#92

Post by toast0 » Thu, Jul 27, 2017, 2:56 AM UTC

Justin_K wrote: post #89

tedunangst wrote: post #87

Earlier quoted context omitted.

Well, it's hard to be specific since nobody ever mentions which patents they're talking about. But I would assume that somebody at AMD has the skills to determine whether Nvidia uses the "good matrix" technique, or whatever it is people are assuming AMD patented that Nvidia is trying to hide.

In court, there's a big difference between your assumption vs. published code.

Drivers are published code, freely available. If the driver does something, and you can't find an expert witness to testify it does what it does, maybe it doesn't do what you think?

Reading assembly with no comments is a different skill than reading C or C++, especially since it's not always clear what's an instruction and what's data, but it's still reading code, and there are tools to help you trace through it. And most of the drivers aren't writing code like it's a 64k demo (where the code is the data, and the data is the code, and they both modify each other)

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

#93

Post by astrange » Thu, Jul 27, 2017, 3:02 AM UTC

shitgoose wrote: post #77

CobrastanJorji wrote: post #28

Earlier quoted context omitted.

I assume they mean that C's support for "arrays" is essentially just C's support for pointer arithmetic plus a mapping of a[b] to *(a+b).

shouldn't it be: * (a + b * sizeof(T)) where T is array elements' type?

That's implied in + on a pointer. uint32_t* + 1 actually adds 4.

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

#94

Post by astrange » Thu, Jul 27, 2017, 3:04 AM UTC

JustSomeNobody wrote: post #26

frlnBorg wrote: post #23

Earlier quoted context omitted.

What do you mean by C not having arrays?

Probably referring to the fact that they are simply pointers into contiguous memory.

C doesn't have "memory" in the standard. They're pointers into a contiguous object, but anything before a[-1] or after a[sizeof(a)-1] is undefined aka it actually doesn't exist.

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

#95

Post by corndoge » Thu, Jul 27, 2017, 3:04 AM UTC

sbierwagen wrote: post #66

corndoge wrote: post #48

Earlier quoted context omitted.

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

You consented to it, sure. This bug affected millions of phones. It's more like a car manufacturer decided to put a particular explode-y gas tank in a car, because it provided greater performance.

and they put a note in the manual that says "if you drive over 70mph on a hot day it will definitely explode so don't do that"

so if you buy that car and you do that, it's your fault regardless of how poor the car design is

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

#96

Post by corndoge » Thu, Jul 27, 2017, 3:06 AM UTC

MaulingMonkey wrote: post #67

corndoge wrote: post #48

Earlier quoted context omitted.

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

My experience is that most C programmers don't know about many of the caveats about the C programming language. Are you aware that atoi("a"); is undefined behavior? It can crash, it can launch nethack, it can return 0.

yes I'm aware that parsing a letter as an an integer is undefined behavior, it's in the manual

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

#97

Post by corndoge » Thu, Jul 27, 2017, 3:08 AM UTC

simonh wrote: post #58

corndoge wrote: post #48

Earlier quoted context omitted.

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?

never said C was a great language, merely indicated that it's important to distinguish between a mistake made by a programmer and a failure of the language

pretty sure trusting user provided data without validation is the programmers fault regardless of language

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

#98

Post by corndoge » Thu, Jul 27, 2017, 3:09 AM UTC

teraflop wrote: post #50

corndoge wrote: post #48

Earlier quoted context omitted.

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

If thousands of people were repeatedly making the same mistake, and frequently shooting other innocent bystanders' feet, I would definitely put some blame on the manufacturer.

the parents analogy is quite bad since C doesn't shoot you in the foot unless you pull the trigger

closer to a gun without a safety, which plenty of manufacturers sell

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

#99

Post by yborg » Thu, Jul 27, 2017, 3:15 AM UTC

spudlyo wrote: post #5

shock wrote: post #2

This is kind of scary :(. How does one ensure that they aren't vulnerable to this bug?

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.

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

#100

Post by hedora » Thu, Jul 27, 2017, 3:35 AM UTC

thomastjeffery wrote: post #24

whowouldathunk wrote: post #19

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 .

I'd argue most wifi chipsets do not have working drivers, but I have an apparently high bar for "working": It has to stay authenticated to a given access point indefinitely, can't kernel panic or require reboots to switch to a new network, and needs to have competitive throughout and tail latencies under load.

Most wifi adapters fail at least one of these requirements under windows or linux.