
Over the Air: Exploiting Broadcom’s Wi-Fi Stack - ivank
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
======
mrb
How ironic. Yesterday on HN someone said " _Google Security Team, here 's your
call to stop pontificating on the Project Zero blog and throwing cheap muck at
Microsoft. You've got an even bigger and more complicated mess to clean up,
you dug the hole yourself, it's going to take you longer, and you should have
started on it years ago_" [1]

And today we have this very impressive counter-example of Google putting some
engineers to work for _months_ doing vuln research for making, in the end,
EVERYONE safer: Apple users, Samsung users, and hundreds of other mobile
device vendors who use this popular Broadcom Wi-Fi chipset in products shipped
to 1B+ users.

But no, somehow, tomorrow again it is going to be all Google's faults that
Android-derived commercial works are insecure and poorly maintained by their
respective vendors.

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

~~~
berberous
Google has 57,000 employees. There is always going to be some good, some bad,
in an organization that size.

The Project Zero team is excellent and we should all be grateful for their
work. But we should also continue to hold Google's feet to the fire on the
state of Android security, since it is truly a mess, and they are probably the
only player to have the power and ability to fix it.

~~~
mrb
Android is open source and has a permissive license. Fundamentally this means
Google cannot prevent manufacturers like Samsung from shipping insecure phones
receiving infrequent software updates. I am curious as to what you think
Google "should" do? Make Android closed source like iOS and ship it as binary
blobs and a license forcing manufacturers to ship sw updates exactly when
Google says to do so? You think phone manufacturers would agree to that? They
would promptly fork off the last open source Android and rarely take Google's
subsequent updates.

If you want a phone with top-notch security, buy a Google phone which is
guaranteed, _by Google_ , to come with 3 years of monthly security updates.

~~~
peterwwillis
If Microsoft had required Dell, HP, Lenovo, Samsung, Toshiba, Acer, Asus, etc
all to provide free operating system upgrades on your PC every time there was
a Microsoft security hole, Windows would have been deader than dirt years ago.

Google gets away with this because it is "free", so the refrain is "you can't
complain if it's free". Google could go the same route Microsoft did, but it
chooses not to.

Phone manufacturers would be happy to have binary blob updates for free - but
it would never happen. Google would have to custom-build, test, and certify
every binary blob for every piece of hardware, which is an unjustifiable cost.

If you want a phone with top-notch security, buy an Apple phone. They're
supported longer, they fix their security bugs promptly, and they honestly
have a better model for their OS anyway. (disclaimer: I hate Apple)

~~~
cwyers
> If Microsoft had required Dell, HP, Lenovo, Samsung, Toshiba, Acer, Asus,
> etc all to provide free operating system upgrades on your PC every time
> there was a Microsoft security hole, Windows would have been deader than
> dirt years ago.

What? Double what? Microsoft doesn't require this because they don't require
they have a stable driver ABI, so Microsoft can ship updates to Microsoft code
without requiring that device manufacturers ship updated drivers to go with.

~~~
zrm
And so we come to the root of the problem.

Either Android/Linux needs a stable driver ABI, or somehow (looking at you
Google) the hardware vendors have to be convinced to release driver source.

Last weekend I installed the latest Debian on a Pentium II from 1997. What
madness that I can't install the latest Android on a three year old phone?

~~~
kogepathic
_> What madness that I can't install the latest Android on a three year old
phone?_

Unfortunately I think this falls to Linus and the kernel developers.

The ARM portions of the kernel are a fucking dumpster fire of epic
proportions.

Because every SoC vendor can bolt on different components, there is a
truckload of one off code in the kernel to handle every variation of an SoC a
vendor makes. Couple this with the fact that there are very few rules
governing where and how vendors connect external devices via IO, and you have
code for specific boards to ensure they work.

It's simply not maintainable. Many ARM boards ship with heavily patched
kernels, which while having their source code released, will never be merged
into the mainline kernel because of lack of effort by the manufacturer or
simply the kludgy nature of the code offending the good senses of kernel
developers.

Where Google can help is by preventing manufacturers from shipping a device
with Android unless their kernel changes have been accepted to mainline Linux.
This is the only way to ensure support for multiple years.

Actually, that will only help devices which have Google Play Services. Since
Android is open source Chinese manufacturers can just release their own builds
based off AOSP which don't include Google Play Services and then Google has
absolutely no recourse.

------
scarybeast
This is one of the most serious and instructive pieces of technical security
work we're likely to see this year. In case it hasn't sunk it:

\- This vulnerability affects tons of smart phones (iPhone, Nexus, Samsung
S*). \- The attack proceeds silently over WiFi -- you wouldn't see any
indication you've been nailed. \- Mitigations and protections on WiFi embedded
chips are weak. \- The second blog post will show how to fully commandeer the
main phone processor by _hopping from the WiFi chip to the host_.

Imagine the havoc you could wreak by walking around a large city downtown,
spewing out exploits to anyone who comes into WiFi range :-)

~~~
IshKebab
I may be reading it wrong, but I _think_ you have to be on the same network as
the victim. Still, you're right this is very serious.

~~~
jessaustin
Just set your SSID to "attwifi" or "xfinitywifi" or similar, and lots of
devices will connect automatically.

------
jacquesm
That's going to hurt a lot of folks. Especially those whose manufacturers are
not doing their bit with respect to updates. It's absolutely incredible to me
how sloppy manufacturers are when it comes to keeping phones updated, they
seem to see phones that are older than two years as effectively end-of-life.

Even Google is guilty of this, though to a slightly lesser extent.

See: [http://www.androidpolice.com/2016/06/21/google-support-
site-...](http://www.androidpolice.com/2016/06/21/google-support-site-now-
lists-end-life-dates-nexus-devices/)

So three years or 18 months past sale.

Personally I think that a phone is only end-of-life when it stops to work and
that manufacturers should either offer to buy them back if they don't want to
support them any longer or should be forced to provide security updates.

~~~
wvenable
Manufacturers are used to developing a product and selling that product as-is.
The entire idea of needing to maintain (develop, improve, update) a product
beyond the point of sale is a fairly new one.

I'm sure manufactures are slow to embrace this new reality because consumers
see little value in paying for it.

~~~
danieldk
_The entire idea of needing to maintain (develop, improve, update) a product
beyond the point of sale is a fairly new one._

But not in computers. Even in the 80ies, we would buy new version of MS-DOS
for our existing hardware.

The difference is that on most normal computers (except Apple), software
was/is decoupled from hardware, they have different manufacturers. Software
developers want to reach an as large as possible audience, so it is typically
not in there interest to support only the latest hardware iteration.

~~~
flukus
And PC manufacturers still screw it up. If you're lucky you'll get 4 updates
to a computer spread 6 months apart and delivered by a custom app that is just
as likely to crash as it is to update you're system.

~~~
gmac
... or indeed brick your laptop (as happened to me once with an HP).

------
8_hours_ago
This research is effectively a free audit of Broadcom's firmware by Google. At
what point does Broadcom approach Google, have the appropriate NDAs signed,
and give them access to the source code? If someone is providing a (very
valuable) free service to you, wouldn't you want to make their lives easier?

I assume there are some important reasons why this wouldn't occur, but at
first glance, it seems to me that the pros outweigh the cons.

~~~
IshKebab
Yeah... having worked in actual large secretive companies like Broadcom
they're more likely thinking "Shiiit they found a security vulnerability using
information from the datasheet, a memory-probing utility we provided and some
of our open source code. We've got to make all of those secret!"

~~~
trome
Which is so silly, as closing their code & datasheets just makes it harder to
work with their chips and makes users of their products less secure. And that
is why you see all these Single Board Computers not using Broadcom chips, they
are nearly impossible to get docs for, let alone decent drivers.

------
shock
> Broadcom have informed me that newer versions of the SoC utilise the MPU,
> along with several additional hardware security mechanisms. This is an
> interesting development and a step in the right direction. They are also
> considering implementing exploit mitigations in future firmware versions.

... _considering implementing exploit mitigations in future firmware
versions._ I'm somewhat doubtful that they give much shit unless it hurts
their bottom line. This sounds like lip service. What else are they gonna say?
_" We're not considering implementing exploit mitigations"_?

~~~
tptacek
Modern exploit mitigations in MCUs and RTOS systems are definitely not the
norm.

------
osivertsson
Whoa! This is really impressive stuff, and will cause head-ache in my dayjob
where we develop a product using this WiFi SoC.

Can this vulnerability cause content-owners and DRM vendors to no longer allow
such devices to decode 4K content? I'm thinking of for example PlayReady
certification that may be withdrawn/downgraded because of this issue, but I'm
fuzzy on the details how this would work.

~~~
jessaustin
How do these certifications deal with e.g. rooted devices (rooted by the
device owner, not an attacker)? One suspects that there's not much they _can_
do? If that's the case, why would they worry about this vuln?

~~~
kuschku
Those devices already can’t play DRM content. Or use Android Pay. Or use
Snapchat.

Many apps, and especially all with DRM content, require a fully signed boot,
and if the user at any point even can see what any app is doing, or MitM
anything, will refuse to work.

Google has published a solution for this which uses TrustZone to create a hash
of the system, transmit this to the Google servers, and Google then verifies
the hash, and transmits a token to the servers of the app willing to play DRM
content.

Rooting, or even unlocking your bootloader, already makes your phone useless
today by design. Which makes the work of projects like Replicant harder.

~~~
userbinator
I can't verify them, but a quick search reveals that people have found ways to
use those apps on a rooted device.

~~~
kuschku
Magisk used to work, but now Android trips as soon as the bootloader is
unlocked, making it a lot harder.

------
chillydawg
Project Zero are seriously doing good work here. This attack can passively own
a large portion of all modern smartphones if unpatched against these vulns.

------
hmottestad
My wife has a Huawei P7. Seems like it has the Broadcom chip :(

Huawei has provided exactly 1 update to the phone since it was released. And
only for those living in New Zealand.

Other than clearing out all the trusted wifis and just keeping the home wifi,
is there anything at all that can be done?

------
glasshead969
iOS 10.3.1 patches this exploit.

[https://support.apple.com/en-us/HT207688](https://support.apple.com/en-
us/HT207688)

------
kyrra
For reference, here is the bug[0] that affected Apple that was discussed
yesterday[1]. One commenter on that HN topic noticed that there was 1 other
public bug about Broadcom wifi chips, though it was not the specific one that
affected Apple.

This blog post points to 4 Project Zero bugs for different Broadcom issues.

[0] [https://bugs.chromium.org/p/project-
zero/issues/detail?id=10...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1059)

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

------
caio1982
That is one of the most educative text I've ever read on network
hacking/security, cannot wait for the next part(s)!

------
blumentopf
There's a bug in Apple's EFI driver for BCM4331 cards present on a lot of
older Macs which keeps the card enabled even after handing over control to the
OS. A patch went into Linux 4.7 to reset the card in an early quirk, but I
suspect other OSes can be taken over via WiFi on the affected machines:

[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=abb2bafd295f)

~~~
qb45
This one is soft-MAC I think.

------
thomastjeffery
This is a prime example of why manufacturers (like Broadcom) should _always_
have open source drivers.

Also a prime example of why manufacturers should _always_ allow the user to
update device the software on his/her device.

Broadcom's closed driver stack has gone from the Linux user's headache to a
serious vulnerability in most phones.

When will vendors get it through their respective thick skulls that there is
_no legitimate reason or benefit_ to keeping their drivers proprietary?

------
dleibovic
Is there a way to tell if my android phone received an update to protect
against this exploit?

~~~
Aissen
Unless you have a Nexus or Pixel, it probably hasn't.

