Over the Air: Exploiting Broadcom’s Wi-Fi Stack (Part 2)

In the case of the Broadcom exploits being discussed in this series of articles, yes, the iPhone is almost certainly more secure than most (all?) Samsung devices with Android. In particular, the iOS 10.3.1 update released a week ago addresses "An attacker within range may be able to execute arbitrary code on the Wi-Fi chip" and credits the author of these articles and Google Project Zero. Because most iOS updates aren't carrier restricted (maybe on Verizon?) that update should be available to any device capable of running iOS 10.

If there are corresponding releases from Samsung I don't remember seeing any mention of them, and even so they'd presumably be waiting for carriers to approve them so there's a chance that some of them will be released by the time people are replacing their current phones anyway.

As for LineageOS, they may be able to address things in the driver, but in my somewhat outdated experience most ROMs don't touch the radio firmware. Radio firmware updates are a completely separate item.

In the wild as in "being actively exploited" yes, that's quite possible, but it's not a practical exploit for large-scale hacks on devices.

The required firmware changes are likely to be somewhat different for each version of the radio hardware and firmware and each carrier's OS variants. That means that you'd either need a very sophisticated set of exploit code (which means complicated and bulky when you may not have a lot of space to play with and may be working in hand-optimized assembler) or that you need to narrow your focus to only specified handsets. Even after that, you then have to have a WiFi access point pushing this, so even if you're in a high-traffic area such as a city downtown or an airport you're going to impact a relatively small percentage of devices.

If you have control of a large botnet of compromised WiFi routers you might be able to push this from those, but the more you do that the more likely you are to be discovered, and you're still going to have the problem of selectivity.

What this all translates to is that exploiting this on a wide scale would require a lot of resources and extremely skilled developers while also being at fairly high risk of detection. Using this for highly targeted attacks on the other hand would allow for less work generalizing the attack and could probably go undetected. Further, if someone not a state actor has "weaponized" this their best option for making money on it would likely be to sell the exploit to either a government or to one of the groups who specializes in targeted hacking.

If you do a little bit of "open source intelligence" you can find the author of this exploit used to be employed in an Isreali Defense Force - Elite Technological Unit.

Read between the lines where he got the idea to do an exploit like this.

I see this kind of statement often, but I've yet to see evidence supporting it. The kind of actors who even have the ability to execute this kind of exploit wouldn't easily be stopped by a closed source codebase. My theory is that the security of open source firmware would be equivalent to that of closed source firmware in the worst case.

Only as long as the binaries can't be extracted from the device. Once that is possible there is no reason to put closed source above open source with respect to safety, open source at least has the (debatable) advantage of having a lot of people looking at it. Closed source but binaries available is the equivalent of security by obscurity.

Another way to look at this: if you're into reverse engineering looking at the disassembled code is as good and in some cases even better than looking at the source because the source shows you the intent whereas the assembly shows you what is actually going on which might be subtly different, different enough to sometimes have a little edge.