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

61–70 of 171 posts

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

#61

Post by amazingman »

revelation wrote: post #29
yifanlu wrote: post #21

Earlier quoted context omitted.

> Most modern systems have a MMU to prevent the peripheral from DMAing to memory areas not specifically reserved for it, but given (certainly Android) systems run oldschool kernels hacked together by the last kind of crowd you want working on them it's probably not enabled or setup correctly. I'm not sure it's fair to assume iOS IOMMU isn't set up properly just because that's the case on many (most?) android phones.…

I didn't want to suggest that iOS is insecure because Android systems are. For Android we know most of them are hopeless, on iOS it's security by obscurity all the way with just a generally good "track record". Well, they patched something. Maybe they just patched the firmware image that is loaded onto the chipset on boot and there was no privilege escalation onto the iOS application processor. But if there was, the…

How, specifically, is iOS "security by obscurity all the way"?

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

#62

Post by [deleted] »

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

[deleted]

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

#64

Post by emptybits »

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!)

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

#65

Post by zerocrates »

ben1040 wrote: post #10
yodon wrote: post #7

Earlier quoted context omitted.

Out of curiosity, what fraction of Android OEMs push these security updates promptly (or equivalently what fraction of Android phones receive these kind of updates regularly)?

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.

My TV came with no on-screen menus but a tablet you use to interact with most features and settings: it's on the June... 2016 patch set. It was over half of year out of date before I took it out of the box.

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

#66

Post by sbierwagen »

corndoge wrote: post #48
orf wrote: post #45

Earlier quoted context omitted.

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…

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.

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

#67

Post by MaulingMonkey »

corndoge wrote: post #48
orf wrote: post #45

Earlier quoted context omitted.

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…

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.

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

#68

Post by contingencies »

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 phone screen was eaten alive by fungi last week, so I had a look at the field to pick a new device. Discovered Lineage OS, super keen. Unfortunately, its device support is crap.

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

#69

Post by feikname »

thrownblown wrote: post #13
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.

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.

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

#70

Post by MaulingMonkey »

corndoge wrote: post #33
Animats wrote: 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.

> Programmer's mistake for not validating data, not the fault of C language mechanics.

If you outfitted a police force with guns without safeties and hair-pull triggers, and you have any sanity, you're not going to be surprised if the rate of accidental discharges goes up. Programmers use their programming languages a lot more frequently and with a lot less care.

So, sure, let's tell the programmers to be more careful. But the most careful of programmers know they'll still make mistakes, and seek out ways to aid themselves in catching those mistakes instead of hoping they can will them away. One such aid can be choosing another programming language that doesn't share C's language mechanics.

Put another way - programmer's mistake for choosing to use C's language mechanics. You could argue that's technically not saying it's the fault of C language mechanics, but I'd say that's splitting hairs at the best.

You could share the blame with a failure to properly fuzz, and insufficient use of static analysis. I'd be okay with that too.

Post reply on HN