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

101–110 of 171 posts

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

#101

Post by MaulingMonkey »

corndoge wrote: post #96
MaulingMonkey wrote: post #67

Earlier quoted context omitted.

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

> yes I'm aware that parsing a letter as an an integer is undefined behavior

Excellent!

> it's in the manual

It's not in MSDN: https://msdn.microsoft.com/en-us/library/yd5xkb5c.aspx

It's not in the manpages: https://linux.die.net/man/3/atoi

Cppreference understates it has having an undefined return value, rather than undefined behavior outright: http://en.cppreference.com/w/cpp/string/byte/atoi

Tutorialspoint defines the behavior as returning 0, and fresh2refresh makes no mention of undefined behavior.

My eighth google hit for atoi finally, finally, gets it right: http://pubs.opengroup.org/onlinepubs/9699919799/functions/at...

If you buy or pirate a copy of e.g. the C89 standard, or refer to one of the free draft versions, it's of course properly documented there too. Neither shows up in the first 50 google results, naturally.

And, of course, by google result 9, we're back to square one - incorrectly defining the behavior as being "returning 0": https://en.wikibooks.org/wiki/C_Programming/stdlib.h/atoi

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

#102

Post by hedora »

kuschku wrote: post #40
corndoge wrote: post #37

Earlier quoted context omitted.

Isn't that the definition of an array? Chunk of contiguous memory plus a notion of how to subdivide it into equal parts?

Yes, exactly. A chunk of memory. A chunk has an end. But "arrays" in C aren't a chunk of memory, just the info where it starts and how large elements are.

The problem is that a frightening number of people don't bother to write the half-dozen obvious wrappers around this, and stdlib doesn't provide them either:

struct buf { uint8_t * base, size_t size };

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

#103

Post by MaulingMonkey »

corndoge wrote: post #95
sbierwagen wrote: post #66

Earlier quoted context omitted.

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

There's likely to be a government mandated recall if your car "spontaneously" explodes - some designs are so poor they fail to meet entirely reasonably regulatory standards. Burying the lede in the fine print is not a get out of jail free card for obvious reasons.

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

#104

Post by kbenson »

hedora wrote: post #102
kuschku wrote: post #40

Earlier quoted context omitted.

Yes, exactly. A chunk of memory. A chunk has an end. But "arrays" in C aren't a chunk of memory, just the info where it starts and how large elements are.

The problem is that a frightening number of people don't bother to write the half-dozen obvious wrappers around this, and stdlib doesn't provide them either: struct buf { uint8_t * base, size_t size };

> The problem is that a frightening number of people don't bother to write the half-dozen obvious wrappers around this

That's likely because having to pass it in and out of functions and libs that don't expect your special structure might cause it to have an invalid length, and then all your special wrappers can become a liability and not an advantage through either assuming your bufs are valid, or defensively checking more than is necessarily because they can't know whether it was altered or not.

> stdlib doesn't provide them either

Which is the real problem. That would make them a de facto standard, and a lot (but probably not all) of the problems would be mitigated by people accepting the performance trade offs needed to make them safe.

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

#105

Post by ams6110 »

JepZ wrote: post #46
ben1040 wrote: 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

Guess I'll have to look at upgrading my diehard old Moto G. It's still on Android 5.1.1.

Meanwhile I guess disabling WiFi is a mitigation?

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

#106

Post by kbart »

hedora wrote: post #102
kuschku wrote: post #40

Earlier quoted context omitted.

Yes, exactly. A chunk of memory. A chunk has an end. But "arrays" in C aren't a chunk of memory, just the info where it starts and how large elements are.

The problem is that a frightening number of people don't bother to write the half-dozen obvious wrappers around this, and stdlib doesn't provide them either: struct buf { uint8_t * base, size_t size };

That doesn't solve the problem because you still have to set 'size' manually.

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

#107

Post by cyphar »

justbuchanan wrote: post #85
freyir wrote: post #75

Earlier quoted context omitted.

Every wifi chipset has working drivers Every existing Wi-Fi chipset has working drivers. A startup begins from scratch, which is one more barrier to entry.

True, but there are many open-source wi-fi drivers out there already. Unless broadcom's implementation is something out of the ordinary, releasing their driver doesn't really change the game.

And experience with Broadcom's wireless drivers (and NFC chips) tells me that the only thing extraordinary about them is how awful and limited they are.

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

#109

Post by Canada »

wtallis wrote: post #91
paulie_a wrote: post #82

Earlier quoted context omitted.

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.

End users don't really matter to Broadcom. Chip makers don't sell product to end users, they sell to device manufacturers.
Post reply on HN