There's a new Bluetooth vulnerability collection, called BrakTooth. PoCs are under NDA until end of October. Are these bugs real? Do they affect more than the Cypress dev kit, for example, iPhones and MacBooks?

Jan, who developed the Frankenstein emulator for Cypress chips and discovered the BlueFrag vulnerability within Android, joined my efforts in reproducing these bugs. All tooling we used is already public, as well as the BrakTooth vulnerability descriptions. We will not publish our own BrakTooth PoCs until the BrakTooth NDA ends to protect end users.

Link Management Protocol

If you're reading this and already have a background on Bluetooth, continue reading on the next section. Everyone else still needs to get familiar with an over 3k page long nightmare, called "Bluetooth Specification". All page numbers refer to version 5.2, even though version 5.3 was released recently. As of now, there's no 5.3 chip available.

The Link Management Protocol (LMP) negotiates connections and their parameters in Bluetooth Classic. There's also a Link Control Protocol (LCP) in Bluetooth Low Energy, which serves a similar purpose, but expect from that has very different properties. Everything in this post will be about LMP packets as well as their headers.

LMP is available prior to pairing, since it is meant to initiate connections and new pairings. In this state, it provides basic information about the Bluetooth chip: The Bluetooth version and even the Bluetooth subversion, typically being identical to the firmware version. Anyone who knows the lower four bytes of a MAC address can talk LMP to a Bluetooth chip. (This is a lesser-known fact you can try at home using l2ping on Linux, the first 2 bytes can contain arbitrary values.) Even if a chip is not discoverable, meaning that it is not listed in the scan results of other devices, it typically accepts LMP connections. For those who are less familiar with embedded devices, a Bluetooth chip is analogous to a public web server, and everyone who knows its IPv4 address can connect to it and would get immediately all information about the software running on that server.

LMP does not only manage connections, it is also responsible for pairing two devices, starting encrypted sessions, etc. The logic bugs in LMP are endless, and instead of citing >10 papers, all you have to know is that encryption and pairing broke every few months since 2018. Meanwhile, all major vendors built their own key exchange mechanisms on top of Bluetooth. It is hard to find such logic bugs with fuzzing. Instead, one has to read the specification, find weird exceptions and error conditions, and try them on real implementations. In practice, some of these bugs were as simple as "setting a key component to zero" or "request a specification-compliant encryption downgrade".

In addition to not providing any security at all, LMP serves a few other basic tasks, such as negotiating parameters for the physical layer. If something on this layer is misconfigured, connections are dropped. Errors in the LMP state machine easily lead to denial of service, for example in the form of hangs, crashes, or degraded connection quality.

Each LMP packet has up to 17 bytes. The first byte is an opcode, and each opcode has a fixed length payload (p. 679). Nonetheless, parsing these bytes can be error-prone. BrakTooth V1 is a vulnerability in the ESP32 chip, which allows arbitrary code execution for an LMP_features_res_ext packet. Another issue I identified in Broadcom chips (CVE-2018-19860) allows code execution under certain constraints on older firmware for the undefined, vendor-specific opcode 0.

The LMP nightmare doesn't stop here. The BrakTooth researchers were the first to fuzz LMP payloads in combination with headers over-the-air. A Bluetooth packet has two headers: A packet header and a payload header. The curious reader will directly spot the redundant Flow bit, but it's worse than that.

The packet header is also called baseband header in the BrakTooth writeup. It defines the logical transport address (LT_ADDR, p. 450) as well as the packet Type (p. 471). If a type is valid given a certain physical layer modulation scheme is decided by a fair dice roll.

The payload header has yet another length field. This field is 5 bit wide, which means that it could define payload lengths up to 31 bytes.

Depending on the packet type in the packet header, the payload header could also be 2 bytes, meaning that the length field is 10 bit wide, resulting in up to 1023 bytes long packet payloads.

Prior to receiving an LMP packet, the packet and the payload header must be parsed correctly. The combination of changing packet and payload header as well as the payload could lead to overflows and code execution in the worst case, or to very weird protocol parsing states. BrakTooth aims to identify such bugs over-the-air.

Vulnerability Classification

The BrakTooth website lists four vulnerabilities affecting the CYW20735 evaluation kit. The researchers used the official SDK to check if the firmware restarts or rises assertions. This means that they would get messages like DBFW_ASSERT_TYPE_FATAL on the Cypress SDK. They didn't use the Frankenstein heap sanitizer to check if these crashes are memory corruptions. The also didn't attach InternalBlue, which can parse stack dumps when the chip crashes, which further enables debugging in case of potentially exploitable bugs that aren't memory corruptions. Instead, they were running the Cypress rfcomm_serial_port example application from the SDK, without detailed debugging of the chip's state.

Note that these example applications don't connect to a host but are standalone. Thus, the overall behavior of the stack might be a bit different when we attach Frankenstein, which attaches to the Linux BlueZ stack as a host. The LMP implementation is always handled by the controller (the CYW20735 chip), so even if we attach Frankenstein, vulnerabilities within LMP should reproduce.

But before, let's classify if the crashes could be exploitable heap overflows or not. The older ThreadX block buffer structure, as present in the CYW20735 evaluation kit, doesn't have security checks. Each block starts with a 4-byte pointer to the next block. Thus, everything that looks like a controllable 4-byte overflow into the next block could be exploitable.

Is it patched?

The interesting part here is not the Cypress dev kit patch. Cypress has to triage the bugs and also inform Broadcom. Broadcom then needs to inform their customers and develop patches. This process takes rather long. There's a high chance that BrakTooth is not patched on iPhones. Everyone uses Bluetooth on smartphones...

After downloading the latest IPSW, we can extract it, then open the largest DMG and browse to /usr/share/firmware/bluetooth/. No matter if we do this on iOS 14.5.1 or 14.7.1, the file names and sizes are the same. According to the file names, the latest firmware is from January 2021. Depending on the iPhone model, there are different code names. For example, Aladdin is the iPhone Xs, Moana the iPhone 11, Fiti the iPhone SE2020, and all the nuts are the iPhone 12 series.

Dennis Mantz, who initially developed InternalBlue, added basic LMP sniffing and sending capabilities. Moreover, I already found two vulnerabilities within Broadcom LMP (CVE-2018-19860 and CVE-2019-6994). The initial version of InternalBlue only supports the Google Nexus 5 smartphone. I didn't bother too much to port some of the LMP sending capabilities to other chipsets. However, sending arbitrary LMP works for me. And it sufficiently worked for others, for example, the researchers who found the KNOB and BIAS vulnerabilities heavily relied on the Nexus 5 LMP feature.

The Nexus 5 implementation has some shortcomings. We can only send up to 17 bytes of payload. The baseband and payload header are generated later on by the firmware. This is sufficient to trigger some of the BrakTooth bugs according to their description, such as V1, V3, V4 and so on. But we want to reproduce V14, so it's a bit limited. Will 17 bytes be enough to trigger the same overflow? Given that the LMP_max_slots payload is supposed to be 2 bytes, this could work as well.

As a first setup, I use the Nexus 5 as attacking device. My target device is a MacBook Pro 2020 with the BCM4364B3 Bluetooth+Wi-Fi combo chip. This one is a bit special. Even though the MacBook is recent, this chip still connects via UART, not PCIe, and it seems to be based on a Cortex M3 instead of a Cortex M4. Thus, the transport layer is potentially similar to the CYW20735 chip. Moreover, I want to evaluate which packets arrive on the MacBook. Using the Bluetooth PacketLogger from Apple's Additional Tools for Xcode, we can enable LMP logging. Note that this will not work on all device combinations. But once again, it works for me. It's a nice and debuggable setup :)

All Broadcom and Cypress firmwares have an HCI command that enables sending LMP packets. This command is checked against packet lengths. The InternalBlue command fuzzlmp disables this check and we can now send arbitrary LMP payloads to an active connection.

On the MacBook Pro 2020, we can open the PacketLogger and will see all LMP payloads injected by the Nexus 5. So, yaaay, the tooling we built some years ago still works!

[*] Firmware says: Heap Corruption Detected
[*] Firmware says: Prehook
[*] Firmware says: dynamic_memory_sanitizer_lr = 0x02dee5
[*] Firmware says: dynamic_memory_sanitizer_r0 = 0x21134c
[*] Firmware says: dynamic_memory_sanitizer_r1 = 0x211380
[*] Firmware says: dynamic_memory_sanitizer_r2 = 0x07
[*] Firmware says: dynamic_memory_sanitizer_r3 = 0x05c4
[*] Firmware says: pool = 0x20d368
[*] Firmware says: pool->block_start = 0x2135e0
[*] Firmware says: pool->capacity = 0x10
[*] Firmware says: pool->size = 0x0180
[*] Firmware says: *free_chunk = 0x0400090f

The function at 0x02dee5 is hci_sendEvent. This is reasonable, since LMP_max_slots in turn informs the host about the maximum slots using HCI.

Okay, cool, so here we go and have arbitrary code execution? Maybe, not so fast...

New and old vulnerability

Still confused why 17 bytes seem to be sufficient, I try some more stuff. Even a normal LMP_max_slots causes the same behaviour, with a length set to 2 bytes. This is not an LMP overflow. This is something else. 

When connecting to the Linux host with the same iPhone 7 + CYW20735 combo, without any modified LMP packets, there's still a heap overflow in hci_sendEvent. This is just CVE-2019-18614 that triggered. This is also indicated by the affected pool size, 384. If it would be LMP that is overflowing, it would likely be in the pool with 48 byte elements. Quite interesting, because recently, when I tried to reproduce it on purpose, it didn't trigger. And now I can even play music without this CVE triggering any bugs in the firmware, but the Nexus 5 reliably triggers it. Ooops.

Just for reference, these are the block sizes and pools on the CYW20735 dev kit without patches against CVE-2019-18614, and I didn't update the dev kit while I was testing:

> info heap
[*]   [ Idx ] @Pool-Addr  Buf-Size  Avail/Capacity  Mem-Size @ Addr
[*]   -----------------------------------------------------------------
[*]   BLOC[0] @ 0x200498:       48    33 / 36           1872 @ 0x211610
[*]   BLOC[1] @ 0x2004BC:       96    20 / 20           2000 @ 0x211D60
[*]   BLOC[2] @ 0x2004E0:      268     9 / 10           2720 @ 0x212530
[*]   BLOC[3] @ 0x20D344:      384     4 /  4           1552 @ 0x212FD0
[*]   BLOC[4] @ 0x20D368:      384    16 / 16           6208 @ 0x2135E0
[*]   BLOC[5] @ 0x20D38C:      264    15 / 15           4020 @ 0x214E20

So what is the noise that I hear on the iPhone SE2020 (14.7.1), 11 (14.5.1), and the MacBook Pro 2020 (11.5.2)? Apparently, a new vulnerability. But again just something in the LMP state machine and not exploitable beyond DoS. I already reported it, and in fact, it has nothing to do with the LMP_max_slots. It was just me trying to program assembly and doing things horribly wrong. It may or may not be a bug collision with BrakTooth, but it doesn't match any of the BrakTooth vulnerability descriptions.

Setting the packet and payload header

The function DHM_LMPTx pre-processes and sends LMP payloads. LMP payloads are stored into an slist before being sent by the Bluetooth Core Scheduler (BCS). Elements in this slist are 32 bytes long. The first 12 bytes are typically set to zero, but can also contain 4 byte long callback function addresses. At offset 12, the struct continues with the LMP opcode, and then continues with the LMP payload. Offset 29 (=12 + maximum payload length of 17) contains the length. The length is obtained from a handler table (LM_LMPInfoTable and LM_LMPInfoTableEsc4). Setting other lengths at offset 29 and then putting the LMP payload into the slist results in a crash of the Nexus 5 firmware rather than an invalid packet being sent.

Instead of using InternalBlue for the PoC, Frankenstein becomes an option. Technically, it does almost the same as InternalBlue on the Nexus 5. But Frankenstein supports writing patches in C, and we have full symbols for the CYW20735 board since they were leaked in Cypress WICED Studio 6.2.

We need to set the packet and payload headers to exactly reproduce BrakTooth. Jan already did this for EIR packets to build a PoC for CVE-2019-11516. The fact that Frankenstein identified this bug and that it requires an invalid payload header demonstrates that the fuzzer should also be able to identify BrakTooth V14, assuming that randomness and mutations are with us.

What could overflow within LMP?

Based on Frankenstein, Jan and me build a couple of PoCs and try them against the Cypress eval kit. No crash happens. Is this overflow real?

The function DHM_BasebandRx handles LMP packets received via ACL. If the LLID is 0b11 (3), it will call the function lm_LmpReceived. This function adds an LMP packet with the same structure as for transmission to an slist and then calls bthci_lm_thread_SetEvent. This event signals the link manager to process the packet. lm_LmpReceived does not use memcpy with a variable length. Instead, independent from the length field in the payload header, it will copy 20 bytes from the ACL payload. 

int lm_LmpReceived(int ACLConnectionPtr, _DWORD *lmp_payload_20_bytes)
{
  int result; // r0
  int buffer_32; // r4
  void (__fastcall *callback_function)(int, int); // r2

  result = *(unsigned __int8 *)(ACLConnectionPtr + 155);
  if ( !result )
  {
    buffer_32 = lm_allocLmpBlock();// performs dynamic_memory_AllocateOrDie(32)
    *(_DWORD *)(buffer_32 + 12) = lmp_payload_20_bytes[1];// opcode starts at offset 12.
    *(_DWORD *)(buffer_32 + 16) = lmp_payload_20_bytes[2];
    *(_DWORD *)(buffer_32 + 20) = lmp_payload_20_bytes[3];
    *(_DWORD *)(buffer_32 + 24) = lmp_payload_20_bytes[4];
    *(_DWORD *)(buffer_32 + 28) = lmp_payload_20_bytes[5];
    callback_function = *(void (__fastcall **)(int, int))(ACLConnectionPtr + 4);
    if ( callback_function )
      callback_function(ACLConnectionPtr, buffer_32 + 12);
    *(_BYTE *)(buffer_32 + 31) = *(_DWORD *)ACLConnectionPtr;
    *(_BYTE *)(buffer_32 + 30) = 0;
    slist_add_tail((_DWORD *)buffer_32, (_DWORD **)&lmpMsgList);
    result = bthci_lm_thread_SetEvent(0x20000);
  }
  return result;
}

Note that this is one of the many places that would lead to a controlled firmware crash if memory is exhausted (BrakTooth V12 and maybe V15). Moreover, ignoring the length field in an LMP packet header and later on acknowledging it irrespective of the length is not specification-compliant (BrakTooth A1+A2).

The LMP payload will asynchronously be processed by lm_handleEvents. For the event code 0x20000, it calls lm_handleLmpMsg, which gets elements from the slist and either acknowledges them or processes them in lm_HandleLmpReceivedPdu. This LMP reception handler is finally the one that applies the length fields as defined in the Bluetooth specification using the function lm_getLmpInfoType, which accesses the definitions in LM_LmpInfoTable and LM_LmpInfoTableEsc4. Moreover, lm_HandleLmpReceivedPdu calls diag_logRxLmpPkt, which statically logs 17 bytes of the payload, no matter what the actual packet length was. This explains why we will see the additional bytes in Apple's PacketLogger, and why it always reports the LMP length to be 17 bytes, no matter what the actual transmitted packet length was. Thus, these effects are not caused by an overflow, but by handling all LMP packets as fixed length until actually processing their payload.

Even if the LMP_max_slot packet would have 31 bytes of payload, these would be cut once they reach lm_LmpReceived. 

There are still a couple of checks a packet must pass before DHM_BasebandRx gets the packet, as well as some initial copying from the modem.

The modem

There's a big difference between our CYW20735-based PoC and the BrakTooth PoC for the ESP32. The platforms are fundamentally different. While it is possible to control the firmware on the CYW20735 evaluation kit and set modem registers to configure the modulation scheme (aka packet Type field), the payload Length field, etc., the modems might show different behavior.

To further evaluate and compare modem behavior in detail, both, the BrakTooth PoC, the CYW20735 PoC, and ideally an expensive SDR-based setup are required. At the time of writing this article, this is not available.

The Bluetooth Core Scheduler (BCS) in the Cypress firmware has helper functions used during packet reception, called bcs_utilBbRxPktHdr, bcs_utilBbRxPktSetLength, bcs_utilBbRxPyldCheck, etc. When using two Cypress evaluation boards (CYW20735+CYW20819 in our setup), we extract information from these functions.

Once a payload length of more than 17 bytes is set on the attacker's end, the receiver will no longer see this packet in the bcs_utilBbRxPktSetLength function. This function gets length information from the pkt_log register and applies it to a target struct holding packet information. Thus, it is possible that the Cypress modem on the attacker or receiver end withdraws DM1 packets longer than 17 bytes. This could lead to different behavior and explain why our PoC does not lead to a crash.

In addition to DM1 packets (Type 3), the Cypress firmware also accepts 3DH-1 packets (Type 8) with LMP payloads, according to DHM_BasebandRx. 3DH-1 packets can have a regular payload length of up to 85 bytes (p. 485). We can successfully set the type to 3DH-1, this type reaches the function bcs_utilBbRxPyldHdr over-the-air. Nonetheless, the payload is never actually passed on to LMP processing, even if we leave the length field intact. Yet, something in the modem starts spamming a lot of messages, resulting in way more bcs_utilBbRxPyldHdr calls than usual. In our tests, this did not lead to memory exhaustion, but in general, this could be possible.

This is not the first time that we encounter weird modem behavior in combination with setting lengths. The PoC for CVE-2019-11516 sets the EIR header length, similar to the method we used to reproduce the BrakTooth vulnerabilities. On the receiver, the EIR payload is mapped to a memory area of the modem. In this area, the EIR payload is duplicated, meaning that there is a partial copy of the original payload appended to the intended payload.

If BrakTooth triggers a crash or overflow in or via the modem, it is possible that our Cypress-based PoC doesn't reproduce this.

Improper state handling

If we search for improper state handling of LMP packets and their headers in general, the root cause is likely in the DHM_BasebandRx function, which decides if something is an LMP packet, or the aclTaskRxDone function, which initially parses the ACL packet and payload header. The bit and byte fiddling in these functions is super weird and might be error prone. Issues in this function are not related to LMP in particular, but ACL in general, and should've been detected by Frankenstein.

Something that could still cause some trouble is that lm_HandleLmpMaxSlotPdu accesses the current max slots setting for the active ACL connection. This is not related to an out of bounds accesses, but if the max slots setting is applied incorrectly or only on one of the both ends of a connection, this could cause the connection to be terminated, and maybe also lead to issues in the modem. This might be detected by an over-the-air testing approach like BrakTooth but not by Frankenstein.

When we run a PoC that sets the LMP_max_slot to 31 and send it to the MacBook Pro, it terminates all current connections. The LMP_max_slot packet sets the number of slots (BT 5.2 p. 606), and this can be accepted or denied. The max slot setting seems to be applied correctly and afterwards communication stops. This might be the BrakTooth vulnerability.

Based on our triage, we assume that the BrakTooth vulnerabilities also apply to Broadcom chips, but are not exploitable beyond denial of service attacks. With root causes within modem components as well as the ACL and LMP state machines, Frankenstein could not identify them. We are looking forward to the BrakTooth researchers publishing their PoCs, as well as us publishing our PoCs, to test them in practice and against more targets.

Special thanks

We want to thank Matheus Garbelini from the BrakTooth researchers for commenting on our triage attempts with the Cypress evaluation kits, as well as plonk for proofreading this post.