
Over the Air: Exploiting Broadcom’s Wi-Fi Stack (Part 2) - QUFB
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
======
fencepost
This is the kind of thing I'd expect to see utilized by state-level actors who
in many cases may be able to obtain internal technical information and tools
from vendors. I wouldn't expect this to become an in-the-wild exploit, but for
targeted use by agencies with the resources and motivations to identify
specific models, obtain them and test against them this kind of thing should
be relatively easy.

As an example, what kind of Android device is best used for insomniac tweets?
At one point I thought I saw mentioned that it was a Samsung device a
generation or two old, so perhaps a Galaxy S5 suitable for tweeting from the
tub? That's a known-vulnerable device, elderly by Android standards of "who
gets updates" meaning that Samsung and the carriers don't put any priority on
it. Sure you can look at things like LineageOS, but since part of the problem
here is in the proprietary firmware blob of the chipset there may still be
problems that aftermarket OS upgrades aren't going to touch.

For that matter, is Trump's possible change to an iPhone within the last
month[1] related to this, and has it stuck of does he still have a Samsung
floating around as seems to be the case?

[1] [http://money.cnn.com/2017/03/29/technology/trump-iphone-
andr...](http://money.cnn.com/2017/03/29/technology/trump-iphone-android-
twitter/index.html)

edit: more neutral

~~~
jacquesm
I would totally expect this kind of thing to be already in the wild for the
simple reason that people have been saying this sort of thing is possible for
many years, it is just not the sort of thing that once the parties capable of
doing it have found a practical exploit that they are then going to turn
around and publish it to make the world a better place.

On the contrary, it will be hoarded and used against suitable targets.

An earlier hacker news thread around this theme:

[https://news.ycombinator.com/item?id=10905643](https://news.ycombinator.com/item?id=10905643)

~~~
fencepost
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.

~~~
jacquesm
It all depends on who you are. Politician or CEO of a multinational or a
company related to defense? Political activist? Enemy of the state? The
opposition? Hacker?

It doesn't have to be 'large scale' to be effective and given how hidden an
attack like this could be (and how easy it would be to erase the fact that it
was even there) it may have been used on your device and you still wouldn't be
aware of it or able to prove that it was.

------
jacquesm
These write-ups are amongst the best stuff on HN in the last year or so.
Fantastic content.

I'm not too hopeful on getting this kind of problem permanently solved though,
but one thing that could be done is that manufacturers should treat the radio
assembly as hostile rather than friendly.

~~~
ac29
Completely agree. Google gets some rightly deserved hate on HN, but I think
their work on Project Zero and other security efforts is exemplary (I'd love
to see Apple do the same).

Hat as well tip to the many individuals that contribute to Android security
[0]. Especially Chinese companies, academics, and individuals, who often don't
have the best reputation here either, but contribute a huge amount of the
security bug reports to Android.

[0]
[https://source.android.com/security/bulletin](https://source.android.com/security/bulletin)

------
mschuster91
It's about time regulators start to require publication of full firmware
source code and build stacks. Even Google's power apparently is not able to
enforce Android vendors (and IC vendors) to such standards.

The reason is simple: closed-source blobs are a danger to society as they
leave exploitation to those with the highest budget (i.e. secret services) or
a bit of luck (the "usual" rooters). Furthermore, having source code reduces
electronic waste as independent developers can carry on offering support.

~~~
Thaxll
Closed source somehow prevent most exploits to be found. I truly don't believe
that open source would do more good than it would harm the general public.

~~~
Cyph0n
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_.

~~~
xarope
I agree. What OP is saying is akin to "if my lock is stronger, then the bad
guys will go find another target". This never stops targeted attacks, APTs
etc. If anything, it engenders a level of complacency, right up to when a
breach occurs...

(and of course, in the "good ol days" of hacking, being a more difficult
target actually meant being a more prime target, since that's how repuations
are built... oops!)

------
vvanders
> The Wi-Fi chip managed to DMA into the physical address range containing the
> host’s kernel, without any interference! This finally confirms our
> suspicion; either there is no SMMU present, or it isn’t configured to
> prevent the chip from accessing the host’s RAM.

Uf da.

~~~
houst0n_
Grim right? Wonder how many of these devices there are out there...

Can you even update the smmu config via OTA android updates?

------
zkms
Lack of IOMMU and no memory protection on the Wi-Fi IC was really awkward (but
sorta expectable).

However, it's kinda shocking to me that they'd go to the trouble use a magic
ethertype to tag internally-originating synthetic frames but completely
neglect to strip out __externally-originating __frames with that magic
ethertype.

~~~
greglindahl
I'm less shocked by that than I am by the fact that they still apparently
aren't hiring external auditors. At this point it seems to me that it would be
cheaper to hire an auditor (even _after_ initial shipment, so no time-to-
market problem) than to get black eyes like this one.

------
tudorconstantin
Wouldn't this type of attack also apply to routers containing broadcom chips?

------
sebcat
If you have a raspberry pi, you can see the 886c etherframes in
libpcap/tcpdump captures. At least on a RPi 3 with Arch Linux ARM.

