7 ms·

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

179 points by QUFB 10y ago

jacquesm 10y ago
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 10y ago
  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
vvanders 10y ago
> 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_ 10y ago
  Grim right? Wonder how many of these devices there are out there... Can you even update the smmu config via OTA android updates?
mschuster91 10y ago
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.
- jacquesm 10y ago
  Why stop at phones? How about: tractors, cars, appliances and so on.
- Thaxll 10y ago
  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 10y ago
    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 10y ago
      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!)
  - jacquesm 10y ago
    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.
fencepost 10y ago
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-android-twitter/index.html http://money.cnn.com/2017/03/29/technology/trump-iphone-andr... edit: more neutral
- trendia 10y ago
  Is the iPhone actually more secure than a Samsung running Android? And I don't think LineageOS is going to fix the problem since it (probably) uses the same Broadcom driver in the Linux kernel.
  - fencepost 10y ago
    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.
zkms 10y ago
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 10y ago
  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.
sebcat 10y ago
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.
tudorconstantin 10y ago
Wouldn't this type of attack also apply to routers containing broadcom chips?

179 points by QUFB 10y ago

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 10y ago
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

vvanders 10y ago

> 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_ 10y ago
Grim right? Wonder how many of these devices there are out there... Can you even update the smmu config via OTA android updates?

mschuster91 10y ago

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.

jacquesm 10y ago
Why stop at phones? How about: tractors, cars, appliances and so on.
Thaxll 10y ago
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 10y ago
  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 10y ago
    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!)
- jacquesm 10y ago
  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.

fencepost 10y ago

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-android-twitter/index.html http://money.cnn.com/2017/03/29/technology/trump-iphone-andr... edit: more neutral

trendia 10y ago
Is the iPhone actually more secure than a Samsung running Android? And I don't think LineageOS is going to fix the problem since it (probably) uses the same Broadcom driver in the Linux kernel.
- fencepost 10y ago
  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.

zkms 10y ago

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 10y ago
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.

sebcat 10y ago

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.

tudorconstantin 10y ago

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