Hacking Potential Switch Entry Point [HardMAC]

[Selver]

TLDR; Switch may have network SoC that can be compromised... No exploit is even close in time for the Switch, but the possibility of a hardware-based hack that is difficult to fix may now exist....


Apple's iPhone and many, many other vendors' phones use Broadcom's HardMAC chipset, which provides a System-on-Chip that abstracts many low-level Wi-Fi details. Of course, that abstraction also results in complexity.

On April 4th, the following chromium bug report log became public:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1046

On the same day, the following blog report was published, covering the substantial work involved.
https://googleprojectzero.blogspot.com.au/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html

Also on the same day, Plutoo tweeted that NS on switch has fallen:
https://twitter.com/qlutoo/status/849217859662348290

And, a user "coincidentally" asked if the Broadcom firmware file was available in decrypted form from this NS break.
https://twitter.com/laginimaineb/status/849347353299603458
My guess is that user is familiar with the above SoC firmware break in BCM chips...

NOTE: The above blog post is an excellent example of how difficult reverse engineering is, including the difficulty of creating a usable exploit from a confirmed bug....


Here's a bullet-point:

• Research may apply to the Switch's networking chipset
  • Research was on BCM4358
  • Broadcom claims newer versions use the built-in memory protection units
  • Switch uses BCM4356 (apparently older version in Switch)
• BCM firmware...
  • puts ROM at 0x0 and RAM at 0x180000
  • parses network packets with an essentially static heap layout
  • first bug corrupts internal heap, with attacker-controlled next pointer
  • ... which is then allocated for next packet.
  • has a vendor-unique command that, if heap is corrupted from above, allows attacker-controlled data to be written to that allocation... the location of which was attacker-controlled from the prior bug
• The ROM for the BCM line has a software-based version, with open source, making reverse-engineering of the SoC ROM slightly-less-than-impossible

As you know, the Switch uses ARM TrustZone to at least some degree. But, access to memory by authorized peripherals (on at least some buses) occurs at the security level of the caller.

Anyone want to guess if the Switch kernels use networking capability... e.g., for firmware updates?

 

[Selver]

Reserving for additional notes/updates.

 

[proflayton123]

This is juicy even tho I don't own a switch yet

 

[Wolfvak]

• Broadcom claims newer versions use built-in memory protections of ARM4

Source?

 

[Selver]

Source?

Hi Wolfvak,
See https://googleprojectzero.blogspot.com.au/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html, the section at the very end titled "Wrapping Up".

"Broadcom have informed me that newer versions of the SoC utilise the MPU, along with several additional hardware security mechanisms."

So, any resulting hardware exploit would be time-limited - until updated ROMs are shipped, or they patch the function via their patching capability (in RAM... but so little space available!).

 

[Wolfvak]

Hi Wolfvak,
See https://googleprojectzero.blogspot.com.au/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html, the section at the very end titled "Wrapping Up".

"Broadcom have informed me that newer versions of the SoC utilise the MPU, along with several additional hardware security mechanisms."

So, any resulting hardware exploit would be time-limited - until updated ROMs are shipped, or they patch the function via their patching capability (in RAM... but so little space available!).

These security measures are hardly ARM4... I read that article a couple of hours ago and it stated these chipsets included a Cortex-M4. These are essentially a better version of M3 CPUs, with just DSP/FPU instructions added.

Cortex-M3 CPUs fall under the ARMv7-M family, not ARM4 (or ARMv4).

 

[Selver]

These security measures are hardly ARM4... I read that article a couple of hours ago and it stated these chipsets included a Cortex-M4. These are essentially a better version of M3 CPUs, with close to nothing being added, just smaller clock cycles and such.

Cortex-M3 CPUs fall under the ARMv7-M family, not ARM4 (or ARMv4).

You're absolutely right ... I had ARM-on-the-brain. Fixed. Thanks for paying attention!

 

[Selver]

For those wanting data on the BCM4356, Cypress bought the product line...

Spoiler: Part and datasheet links

BCM4356XKUBG == CYW4356XKUBG
Product Page @ http://www.cypress.com/part/cyw4356xkubgt
Datasheet @ http://www.cypress.com/file/298796/download
This is the 192-pin ball-grid-array package.

Spoiler: Pins of interest

Spoiler: SDIO Pins

SPSDIO pins are at [ABC]:[89]:

• A8 = CLK
  A9 = CMD
  B8 = DAT0
  B9 = DAT2
  C8 = DAT3
  C9 = DAT1

Spoiler: PCIe Pins

PCIe pins are at [ABC]:[54321] and D5
A5 = PCIE_REFCLKN - PCIe differential clock input
A4 = PCIE_REFCLKP - PCIe differential clock input
A3 = PCIE_TDN0 - PCIe transmitter differential pair
A2 = PCIE_TDP0 - PCIe transmitter differential pair
B5 = PCIE_PLL_AVSS - Ground for PCIe PLL
B4 = PCIE_RXTX_AVSS - Ground for PCIe Tx/Rx pairs
B3 = PCIE_PLL_AVDD1P2 - 1.2V supply for PCIe PLL
B2 = PCIE_RXTX_AVDD1P2 - 1.2V supply for PCIe Tx/Rx pairs
B1 = PCIE_RDN0 - Receiver differential pair
C1 = PCIE_RDP0 - Receiver differential pair
C5 = PCIE_PME_L - PCIe power management event output
C4 = PCIE_PERST_L - PCIe system reset
C3 = PCIE_TESTP - PCIe test pin
C2 = PCIE_TESTN - PCIe test pin
D5 = PCIE_CLKREQ_L - clock request signal

Spoiler: Other

A10 = WL_REG_ON (turns WLAN on/off)

Why are the pinouts of interest? If using SDIO, then the pins are close to the edge, and may enable man-in-the-middle tracing with small hardware hacks. For example, perhaps initialization of the WiFi might be done manually (not by original system).

If using PCIe, then there is the potential to insert PCIe bridge, similar to earlier PS4 hacking methods. While slow and costly, the potential for increased understanding of the system working would be high.

 

[Selver]

The impact of this hardware flaw (portions are baked into the ROM) are starting to be realized.
Partial logs from #switchdev:

<@profi200> https://gbatemp.net/threads/potential-switch-entry-point-hardmac.466814/ lol wtf has NS to do with this?
<@profi200> I doubt it's that useful. It may make the attack surface bigger but that's it.
<@profi200> It would really surprise me if it is connected over PCIe.
... next day ...
<yifanlu> https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html?m=1
<@profi200> I really doubt it uses PCIe. It's expensive enough.
<yifanlu> What do you mean by expensive?
<yifanlu> The bcm4356 supports pcie and the Tegra X1 has enough pcie interfaces. It's only a matter of wiring them up.
<@profi200> Apparently the hw costs 257$.
<@yellows8> x1 datasheet mentions it but no idea if wifi-hw actually uses it.
<yifanlu> According to that post though the theoretical maximum speed of 802.11ac exceeds that of sdio so they would have to use either pcie or usb3
<yifanlu> What's interesting in part 2 is the fact that these wifi chips use pcie now
<yifanlu> Something I was not aware of
<yifanlu> Combine that with how easy it is to hack these wifi chips makes for an interesting attack vector

No, this is not a homebrew level attack vector, at least not for a long time....

 

[Selver]

The second half of exploiting this hardware vulnerability has now been published.
While it is targeting a different OS, the driver is open-source, and thus likely it could be determined if similar issues exist in the switch at relatively low cost:
https://googleprojectzero.blogspot.com.au/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html

With existing information disclosure vulnerabilities, it may be possible that Switch firmware 2.0 would be exploitable using only wifi.

Much research would still need to be done, and Switch firmware anti-downgrade greatly reduces the threat this poses (possibly to 2.0 firmware).