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.
And who's to say another chipset won't have a similar issue?
Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
31–40 of 171 posts
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#32Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#33C'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.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#34I do wonder why most mobile chips are broadcom. There's decent competition from Qualcomm atheros and mediatek.
Dunno if it's still true, but Qualcomm/atheros was more expensive and mediatek was cheap crap.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#35The 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…
They only hijacked the radio chip, they didn't escalate to the main processor. One way of attacking would be to intercept someone's internet traffic, and redirect them to a different site (ie, instead of going to Google, you go to get-hacked which looks just like Google).
They intercept and modify packets to redirect to a web site they control. It exploits the main processor through the browser.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#36Earlier 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…
Right, I'm guessing they just patched the actual wifi chip vulnerability. That's why I would like someone (preferably the author) to disclose if there is indeed a privilege escalation or not and to provide more details if there is.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#37Earlier quoted context omitted.
What do you mean by C not having arrays?
It's syntactic sugar in the sense that arr[i] is just shorthand for *(arr+i) There's no abstraction or 'concept' of arrays there. You are literally just telling the compiler to take a certain pointer and move i steps ahead.
Isn't that the definition of an array? Chunk of contiguous memory plus a notion of how to subdivide it into equal parts?
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#38The 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…
They only hijacked the radio chip, they didn't escalate to the main processor. One way of attacking would be to intercept someone's internet traffic, and redirect them to a different site (ie, instead of going to Google, you go to get-hacked which looks just like Google).
> 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.
This implies they have code execution on the application processor just from broadpwn (and not additional safari/ios exploits). Hijacking internet traffic is indeed serious but tech blog sites are already picking up on this and blowing it up. Example: https://9to5mac.com/2017/07/20/broadpwn-wifi-vulnerability-i...
> PSA: Update to iOS 10.3.3 to fix serious wifi vulnerability allowing attacker complete control
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#39Earlier 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 .
Every GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#40Earlier quoted context omitted.
It's syntactic sugar in the sense that arr[i] is just shorthand for *(arr+i) There's no abstraction or 'concept' of arrays there. You are literally just telling the compiler to take a certain pointer and move i steps ahead.
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.