Bluetooth Vulnerability: Arbitrary Code Execution On The ESP32, Among Others

Bluetooth has become widely popular since its introduction in 1999. However, it’s also had its fair share of security problems over the years. Just recently, a research group from the Singapore University of Technology and Design found a serious vulnerability in a large variety of Bluetooth devices. Having now been disclosed, it is known as the BrakTooth vulnerability.

Full details are not yet available; the research team is waiting until October to publicly release proof-of-concept code in order to give time for companies to patch their devices. The basic idea however, is in the name. “Brak” is the Norweigan word for “crash,” with “tooth” referring to Bluetooth itself. The attack involves repeatedly attempting to crash devices to force them into undesired operation.

The Espressif ESP32 is perhaps one of the worst affected. Found in all manner of IoT devices, the ESP32 can be fooled into executing arbitrary code via this vulnerability, which can do everything from clearing the devices RAM to flipping GPIO pins. In smart home applications or other security-critical situations, this could have dire consequences.

Other chipsets are affected to varying degrees, including parts from manufacturers like Texas Instruments and Cypress Semiconductor. Some parts are vulnerable to denial of service, while audio devices may be frozen up or shut down by the attack. The group claims over 1400 products could be affected by the bug.

Firmware patches are being rolled out, and researcher [Matheus E. Garbelini] has released code to build a sniffer device for the vulnerability on GitHub. If you’re involved with the design or manufacture of Bluetooth hardware, it might pay to start doing some homework on this one! Concerned vendors can apply for proof-of-concept test code here.

21 thoughts on “Bluetooth Vulnerability: Arbitrary Code Execution On The ESP32, Among Others

  1. It is a plague of all closed-source blob communication stacks. Try to reverse a couple of them and find a bonanza of vulnerabilities in every each one. It is possible to avoid compromising the whole system by writing some bullet-proof driver code when using a wireless SoC only for the comm. But you are to be pwned sooner or later if your secure app is running directly on an wireless SoC. Even using a punny Attiny as an application & crypto coprocessor dramatically rises your chances of your secrets not being diclosed.

      1. We are talking about microcontrollers: they typically don’t run an OS at all or if they do, it’s FreeRTOS or similar — not full-blown desktop-OSes. Your comment doesn’t make any sense in this context.

          1. Yes, because discovering a bug on a separate device is so much better. Sure, it might not give you RCE on your main application processor, but anything capable of running a BT stack is a worthwhile target on it’s own, at least as a springboard to juicer devices.

          1. I’m not choosing the context. The OP *literally* used the word “MCU”. They weren’t talking about general-purpose microprocessors, they were specifically talking about microcontrollers.

  2. There is an excessive confidence in the format of data being received from external sources, which implies in lack of code to verify the integrity of such data and that is the root cause of most of the vulnerability related issues we see nowadays.

    1. Nowadays? Nothing has changed, it has always been about bad c code from the earliest days of networking, read about arpanet and such. It’s the dumb humans who refuse to learn the lesson and keep repeating the same mistakes they’ve made for decades.

  3. Coincidentally, “brack” is also a poor Japanese pronunciation of the word “black,” which makes it blacktooth instead of bluetooth, black as in black hat. I think my definition is better. =D

      1. and then is “karb” which is “brak wspak” which means notch or dent, which is pronounced “carb” as in carburetor or carbon.

        Ok, polish class dismissed for today ;)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.