BrakTooth vulnerabilities impact closed-source Bluetooth stacks used in chips from Espressif, Intel, Qualcomm…

BrakTooth is a family of new security vulnerabilities in commercial, closed-source Bluetooth Classic stacks that range from denial of service (DoS) via firmware crashes and deadlocks to arbitrary code execution (ACE) in certain IoT devices.

A team from Singapore has discovered 16 new security vulnerabilities after evaluating 13 Bluetooth devices from 11 vendors, but after browsing through the list of certified Bluetooth devices with impacted processors, they estimate it could impact 1400 devices.

BrakTooth impacted devices

We can see the list of BrakTooth-impacted SoCs include some familiar names like Intel AX200 (found in many laptops and computers through M.2 cards), Espressif Systems ESP32, Texas Instruments CC2564C, Qualcomm CSR8811/CSR8510, Bluetrum AB32VG1 board (based on AB5301A SoC) which I’ve just reviewed, and more…

The good news is that most vendors have either already submitted a patch or working on it.

BrakTooth firmware patch

Espressif, Infineon (previously Cypress), and Bluetrum already have released patchsets for their firmware. It’s really important to update the ESP32 firmware as they were the only vendor subject to arbitrary code execution (ACE). Harman International and Silbas are still shown as pending since the status is unknown.

Qualcomm will work on a fix for WCN3990/8, but not CSR8811/CSR8510, while Texas Instruments will only work on resolving the issues for CC2564C if customers request it as explained below:

The vendor Texas Instruments has successfully replicated the security issue, however, at this stage has no plan for producing a patch. In particular, according to the Texas Instruments PSIRT team, they will consider producing a patch only if demanded by customers.

Our team approached Qualcomm to inquire whether a patch would be available for the affected devices. We were informed that they are working on a fix for WCN3990/8 and that the security issue reported in Qualcomm CSR8811A08  has been fixed since 2011 only for ROM Versions A12 and beyond. However, new products in 2021 are still being listed to use CSR8811A08, which has no plan to be fixed. Moreover, a patch for the issue on CSR8510A10 …. is not possible …  due to the lack of ROM patch space.

List of Bluetooth Vulnerabilities
List of BrakTooth Vulnerabilities

You may find the full details about the vulnerabilities listed above in the research paper.

BrakToothA silver lining of those vulnerabilities is that we’ve got a new tool to play with the ESP32 Bluetooth Classic Sniffer.  Developed by Matheus Garbelini for bug bounty for three of the BrakTooth vulnerabilities on ESP32, the open-source utility does not interact with the Bluetooth network like passive sniffers, but as an active sniffer, it connects itself to the remote BT device (BR/EDR target) and allows testing the BT protocol down to the Baseband layer while guided by a BT host stack such as blue-kitchen. The ESP32 Bluetooth Classic Sniffer can work on inexpensive boards like ESP32-DOIT or ESP32-DevKitC.

You can see how BrakTooth vulnerabilities can be exploited with a denial-of-service attach using a Bluetooth headset as a test device.

YouTube video player

The BrakTooth PoC Tool is available to researchers, Bluetooth semiconductor, module, and OEM vendors only until October 30, 2021, after which it will be made public.

Via ThreatPost and thanks to Zoobab for the tip.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

7 Replies to “BrakTooth vulnerabilities impact closed-source Bluetooth stacks used in chips from Espressif, Intel, Qualcomm…”

  1. OK vendors are providing fixes, but bluetooth is deployed in a number of places which will never receive updates, or at least not quickly. I’m particularly thinking about cars, which receive updates less than once a year for example. There could be some fun to have there if the BT stack manages to crash the gadget computer inside.

      1. Not gonna rule it out but if it’s well engineered the two systems will be completely separate. Crashing an infotainment system shouldn’t stop your brakes working.

    1. Some cars are indeed susceptible to the security vulnerability, and so are planes. From the paper:

      … automotive multimedia electronic control units (PMP3), automotive infotainment systems (Volvo FH) and in-flight audio systems such as AMU6500. Notably Volvo FH and AMU6500 are employing Qualcomm CSR8811/510 and Silabs WT32i chipsets,

      1. Ah excellent! Most likely the trouble to expect is functions like pairing a phone or opening the car by proximity detection that will stop working, maybe only for a while after a watchdog reboots it. Or the internal panel stopping to respond to users’ requests.

        Note that the notion of separation is always a bit complicated. Some cars like mine only let you control the air conditioner from the touch panel (it’s a real pity), so you could end up with something blowing cold or hot depending on the last setting before it hung. You can also imagine a device turning the radio on at maximum volume while someone drives. It’s not directly related to accessing the brakes but I’m pretty sure it could have very similar effects when the driver is under total stress trying to figure how to turn that off or where to stop! And the list of such jokes can be long, very long…

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC