
Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets - pedro84
https://blog.exodusintel.com/2017/07/26/broadpwn/
======
thomastjeffery
Why does Broadcom insist on proprietary drivers?

How could it possibly be detrimental for Broadcom to have free software
drivers?

This article is a poignant example that it _is_ detrimental for them to
continue to keep their drivers proprietary.

~~~
paulie_a
There is no benefit. They probably have an embarrassing code base that is full
of garbage and a bunch of lawyers paranoid about IP. Why would any manager
suggest to take that risk that has very little potential upside.

It isn't that it would be realistically detrimental, it just has no value to
the individual attempting to change the established course of the ship

~~~
azernik
Judging from what I've seen of their drivers, yeah, their firmware/microcode
is probably an embarrassing bug-ridden code base. But it _also_ represents a
lot of investment in low-level/low-layer features that they would prefer to
hide from competitors (much more sensitive than the higher-layer logic in the
driver proper).

~~~
paulie_a
While I can understand that sentiment and perspective. Those people are wrong,
they are inconveniencing their competitors to a tiny degree and over
estimating the value of those features due to the awful implenation.

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

~~~
corndoge
Programmer's mistake for not validating data, not the fault of C language
mechanics. Yes it would be easier if <hll features>, still gotta be careful.
I've made plenty of these mistakes but never blamed the language.

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

~~~
corndoge
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

~~~
MaulingMonkey
My experience is that most C programmers don't know about _many_ of the
caveats about the C programming language.

Are you aware that atoi("a"); is undefined behavior? It can crash, it can
launch nethack, it can return 0.

~~~
corndoge
yes I'm aware that parsing a letter as an an integer is undefined behavior,
it's in the manual

~~~
MaulingMonkey
> yes I'm aware that parsing a letter as an an integer is undefined behavior

Excellent!

> it's in the manual

It's not in MSDN: [https://msdn.microsoft.com/en-
us/library/yd5xkb5c.aspx](https://msdn.microsoft.com/en-
us/library/yd5xkb5c.aspx)

It's not in the manpages:
[https://linux.die.net/man/3/atoi](https://linux.die.net/man/3/atoi)

Cppreference understates it has having an undefined return value, rather than
undefined behavior outright:
[http://en.cppreference.com/w/cpp/string/byte/atoi](http://en.cppreference.com/w/cpp/string/byte/atoi)

Tutorialspoint defines the behavior as returning 0, and fresh2refresh makes no
mention of undefined behavior.

My _eighth_ google hit for atoi finally, _finally_ , gets it right:
[http://pubs.opengroup.org/onlinepubs/9699919799/functions/at...](http://pubs.opengroup.org/onlinepubs/9699919799/functions/atoi.html)

If you buy or pirate a copy of e.g. the C89 standard, or refer to one of the
free draft versions, it's of course properly documented there too. Neither
shows up in the first 50 google results, naturally.

And, of course, by google result 9, we're back to square one - incorrectly
defining the behavior as being "returning 0":
[https://en.wikibooks.org/wiki/C_Programming/stdlib.h/atoi](https://en.wikibooks.org/wiki/C_Programming/stdlib.h/atoi)

------
yifanlu
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 code execution on
iOS application processor, that means we have a jailbreak right?

~~~
revelation
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 escalation is that there is still a kernel
driver on the application processor talking to the chipset. There is per se no
reason to distrust data coming from the chipset, so these often aren't written
as defensive as they should be and could contain trivially exploitable
assumptions on what the chipset will send and do.

~~~
yifanlu
> 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. According to the author, most
android phones don't even have KASLR which iOS had since iOS6. I would assume
IOMMU exists and is working properly unless someone has evidence otherwise
(quick google shows very little information on iOS + IOMMU). If a DMA attack
is indeed successful on iOS devices, I think that would be substantial enough
to write about.

> The other more obvious privilege escalation is that there is still a kernel
> driver on the application processor talking to the chipset.

I would consider that a separate exploit--but even then you still need a KASLR
bypass (another exploit?) at the very least to gain control.

> so these often aren't written as defensive as they should be

On the contrary, the market rate for a iOS jailbreak chain is upwards $1
million USD so I'd be surprised if a single exploit gives you full system
control.

~~~
revelation
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 obscurity means criminals
can easily look at the patch to see what it was and exploit that while the
public knows nothing.

~~~
Gaelan
> criminals can easily look at the patch to see what it was and exploit that
> while the public knows nothing.

Huh? If criminals can “easily” inspect the patch, why can’t the public?

~~~
doctorless
They can, but ease is a term that is conditional on expertise.

------
swerner
Fortunately, this is being addressed in software updates. Unfortunately,
people who own older devices are left with the vulnerability forever. The
iPhone 4S alone sold ~60 million units (according to Wikipedia) and did not
(and most likely will not) receive any updates.

~~~
yojex
Where can you learn if your device has been patched? I have an iPhone 5S.

EDIT: From another comment [0], unfortunately if you've been holding out on
updates like I have you'll have to upgrade to 10.3.3.

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

~~~
yladiz
Why are you waiting to update?

------
shock
This is kind of scary :(. How does one ensure that they aren't vulnerable to
this bug?

~~~
ben1040
If your Android OEM has pushed the July 2017 security update to your device,
you're patched.

[https://source.android.com/security/bulletin/2017-07-01#broa...](https://source.android.com/security/bulletin/2017-07-01#broadcom-
components)

~~~
yodon
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)?

~~~
ben1040
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...](https://android-
developers.googleblog.com/2017/06/2017-android-security-rewards.html)

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.

~~~
JepZ
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

~~~
ams6110
Guess I'll have to look at upgrading my diehard old Moto G. It's still on
Android 5.1.1.

Meanwhile I guess disabling WiFi is a mitigation?

~~~
kbenson
> Meanwhile I guess disabling WiFi is a mitigation?

That's a good question. If it's disabled in firmware and not actually powered
down, it might still be susceptible.

------
nyolfen
i've been hearing people complain about the seriousness of this attack vector
for years. i'd be surprised if there weren't intelligence agencies that have
utilized it already.

------
samat
Could please someone explain, 1) if firmware is stored on a Wifi chip or
rather loaded during the boot process?

2) Do apple/google have binary image from Broadcom or rather source code?

It is quite interesting how this patch production/delivery process works.

~~~
dewyatt
> 1) if firmware is stored on a Wifi chip or rather loaded during the boot
> process?

Typically it's loaded during the boot process. On Linux, see the binary blobs
in /usr/lib/firmware or:
[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git)

Source: I did some work with some broadcom (wired) firmware years ago and
found it to be pretty unpleasant.

[http://ipxe.org/gsoc/bnx2](http://ipxe.org/gsoc/bnx2) and
[https://github.com/dewyatt/bnx2-fw-utils](https://github.com/dewyatt/bnx2-fw-
utils)

~~~
azernik
I worked with both QCA and Broadcom wireless, and can confirm. Generally a
version of the driver is compatible with only a specific version of the
firmware; the system manufacturer gets the driver source and a firmware binary
as a package.

------
IshKebab
How long until someone unleashes this? There are going to be millions of
vulnerable Android phones for at least a couple of years to come. Surely it
will happen.

------
mangix
I do wonder why most mobile chips are broadcom. There's decent competition
from Qualcomm atheros and mediatek.

~~~
mmagin
Dunno if it's still true, but Qualcomm/atheros was more expensive and mediatek
was cheap crap.

------
cpach
If anyone wonders, this was patched in iOS 10.3.3
[https://threatpost.com/apple-patches-broadpwn-bug-in-
ios-10-...](https://threatpost.com/apple-patches-broadpwn-bug-in-
ios-10-3-3/126955/)

------
rca
[http://boosterok.com/blog/broadpwn/](http://boosterok.com/blog/broadpwn/)
shows a simple check using hostapd to see if a device is vulnerable

------
amazingman
I already updated my phone. Is the iOS update that patches this available over
a cell network? If not, as is usually the case, isn't that Not Good?

~~~
emptybits
10.3.3? "This update requires a Wi-Fi network connection to download."
Frustrating. I read this update may be 80-100 MB. Apple, please let me use my
mobile data as I see fit. (And a security patch is certainly a worthy use!)

~~~
eisa01
Agree, this is irresponsible to not let us update over cellular

I'm currently on vacation, which means that most of the wifi hotspots I'm
connecting to are public. That's a big security risk in itself

~~~
thesmok
iOS security update files are crypto signed, so it's safe to download them on
public WiFi.

~~~
fragmede
Not in this case.

If your wifi chipset is known to be compromised, and there is a remote exploit
available, as in this case, then merely connecting with wifi to an evil
hotspot is enough to compromise a device.

Once a device's been compromised, crypto signatures on update files won't
protect you, as the signature checking itself can no longer be trusted.

------
anon4728
Proprietary drivers, firmware blobs _and ASICs_ are a national security
threat. Without open code reviews, auditing and functional verification it's
impossible to trust there are both a minimum of exploitable bugs and/or
backdoors in a given software-hardware stack. This may require some sort of
confidentiality rubric but there's no shortcut to getting around this vital
need.

