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

41–50 of 171 posts

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

#41

Post by viraptor »

revelation wrote: post #20
yifanlu wrote: post #12

The article mentions > Broadpwn is a fully remote attack against Broadcom’s BCM43xx family of WiFi chipsets, which allows for code execution on the main application processor in both Android and iOS. But it doesn't go into any details on this privilege escalation actually works for iOS and more specifically that it doesn't require additional exploits. Can anyone explain this in more detail? If this actually allows co…

The block diagram shows a PCIE connection to the application processor, which enables DMA. 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. The other more obvious privilege esca…

> hacked together by the last kind of crowd you want working on them

That was neither informative nor necessary, really... (And likely not true)

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

#42

Post by Kubuxu »

CobrastanJorji wrote: post #28
frlnBorg wrote: post #23

Earlier quoted context omitted.

What do you mean by C not having arrays?

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

You can even swap it a[b] equivalent to b[a].

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

#43

Post by gruez »

merb wrote: post #8
excalibur wrote: post #4

Earlier quoted context omitted.

Don't use any devices with a Broadcom Wi-Fi chipset.

which basically means don't use any wifi. I think at least 60% of all wi-fi chipsets are broadcom ones.

that seems pretty doable. on phones there's qualcomm chipsets, and on desktops/laptops there's atheros, intel, and realtek (of the vendors i know of).

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

#44

Post by thomastjeffery »

johncolanduoni wrote: post #39
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 GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.

Comparing a Wifi chipset to a video card is like comparing a bicycle to a sports car.

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

#45

Post by orf »

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.

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 language that's used in a lot of complex parsing code and provides pretty much nothing to help with this, and if anything actually puts roadblocks in the way.

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

#46

Post by JepZ »

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.

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

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

#47

Post by revelation »

viraptor wrote: post #41
revelation wrote: post #20

Earlier quoted context omitted.

The block diagram shows a PCIE connection to the application processor, which enables DMA. 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. The other more obvious privilege esca…

> hacked together by the last kind of crowd you want working on them That was neither informative nor necessary, really... (And likely not true)

The leading Android smartphone producer Samsung had on at least two of their flagship phones a world RW device that allowed full access to the entire system memory including the entirety of the kernel, deliberately:

http://www.securitytracker.com/id/1027894

They needed it to get the camera working. This is not an exaggeration, the people they have writing software for their phones will take every shortcut they can find or imagine to deliver another bullet point on the feature list. Security be damned.

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

#48

Post by corndoge »

orf wrote: post #45
corndoge wrote: post #33

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.

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

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

#49

Post by monocasa »

johncolanduoni wrote: post #39
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 GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.

The driver 'optimizations' in GPUs tend to boil down to hand written replacements for unoptimal/broken shaders and API call sequences on a per application basis.

I expect a network card to not 'interpret' my traffic in a similar way.

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

#50

Post by teraflop »

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

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.
Post reply on HN