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

81–90 of 171 posts

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

#81

Post by [deleted] »

feikname wrote: post #69
thrownblown wrote: post #13

Earlier quoted context omitted.

Manufacturer: Device(S) BlackBerry: PRIV Fujitsu: F-01J General Mobile: GM5 Plus d, GM5 Plus, General Mobile 4G Dual, General Mobile 4G Gionee A1 Google: Pixel XL, Pixel, Nexus 6P, Nexus 6, Nexus 5X, Nexus 9 LGE: LG G6, V20, Stylo 2 V, GPAD 7.0 LTE Motorola: Moto Z, Moto Z Droid Oppo: CPH1613, CPH1605 Samsung: Galaxy S8+, Galaxy S8, Galaxy S7, Galaxy S7 Edge, Galaxy S7 Active, Galaxy S6 Active, Galaxy S5 Dual SIM, Ga…

Just a disclaimer, this isn't the complete list of devices that received the July 2017 update. I, for one, received it for my Moto G4 Play in Brazil. This list shows the models with a MAJORITY OF DEPLOYED DEVICES running a security update from the last two months.

[deleted]

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

#82

Post by paulie_a »

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

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

#84

Post by eisa01 »

emptybits wrote: post #64
amazingman wrote: post #63

I already updated my phone. Is the iOS update that patches this available over a cell network? If not, as is usually the case, isn't that Not Good?

10.3.3? "This update requires a Wi-Fi network connection to download." Frustrating. I read this update may be 80-100 MB. Apple, please let me use my mobile data as I see fit. (And a security patch is certainly a worthy use!)

Agree, this is irresponsible to not let us update over cellular

I'm currently on vacation, which means that most of the wifi hotspots I'm connecting to are public. That's a big security risk in itself

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

#85

Post by justbuchanan »

freyir wrote: post #75
thomastjeffery wrote: post #24

Earlier quoted context omitted.

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 .

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.

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

#86

Post by nosajm »

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

My five-year-old Samsung S3 for Verizon stopped receiving updates less than 2 years after its release. The bootloader is locked tight, so I am unable to install any custom ROMs such as Lineage OS.

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

#87

Post by tedunangst »

freyir wrote: post #74
tedunangst wrote: post #60

Earlier quoted context omitted.

This seems unlikely. (Or maybe that's the reason given, but it seems implausible to be true.) Competitors have more than enough know how to determine if you're infringing a patent, source or no source.

> Competitors have more than enough know how to determine if you're infringing a patent How do you figure? The detectability of infringement is a key factor in deciding whether to file a patent. Regardless, copyright infringement might also be an issue.

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.

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

#88

Post by anon4728 »

Proprietary drivers, firmware blobs and ASICs are a national security threat. Without open code reviews, auditing and functional verification it's impossible to trust there are both a minimum of exploitable bugs and/or backdoors in a given software-hardware stack. This may require some sort of confidentiality rubric but there's no shortcut to getting around this vital need.

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

#89

Post by Justin_K »

tedunangst wrote: post #87
freyir wrote: post #74

Earlier quoted context omitted.

> Competitors have more than enough know how to determine if you're infringing a patent How do you figure? The detectability of infringement is a key factor in deciding whether to file a patent. Regardless, copyright infringement might also be an issue.

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.

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

#90

Post by kurthr »

tedunangst wrote: post #60
Scramblejams wrote: post #51

Earlier quoted context omitted.

One theory I've seen bandied about related to GPU drivers is that it's harder for your competitors to notice you're infringing on their patents if you don't ship your source code.

This seems unlikely. (Or maybe that's the reason given, but it seems implausible to be true.) Competitors have more than enough know how to determine if you're infringing a patent, source or no source.

The US legal system has discovery for patent cases. You can sue and then subpoena their code base to confirm whether they are in violation before going to court (and really racking up the fees). Since these are US companies I think that it's more likely fear that others would see the horrible hacks or clever trade secrets.

In other countries (most of Asia), where there is no discivery, it's almost impossible to prove hardware or software patent violations so your case is kicked out of court immediately, even if your patent claims are valid and their product reads into your claims. That's why most patent suits end up in the US or Europe (or in the even faster ITC import injunction).

Post reply on HN