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.
ESP32 already took care of this issue back on Sept 9’th.
Unfortunately patching it in SDK is only the beginning. Most devices will not be updated, and even most developers probably won’t update their SDK.
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.
Conclusion don’t have complex 3rd party sw stack on main MCU.
Who needs an operating system? Write it all from scratch! Yeah that’s how you get a secure app.
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.
And for that matter, we’re also only talking about the main MCU. Having the complex 3rd party BT stack but on a separate device is already much better.
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.
My comment doesn’t make sense except for when it make sense??? Why do you get to choose the context?
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.
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.
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.
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
‘brak’ in polish means ‘lack’ like in lack of.
Interestingly it also means a faulty product on a production line, more officially known as “produkt wybrakowany”.
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 ;)
I can’t wait to see a disclosure only to find out if this vulnerability can be fashioned into portable BT speaker killer (or at least jammer).
From the disclosure site (braktooth.com): https://www.youtube.com/watch?v=tmsBawHqkSU
PS4?
Unlikely, because the playstation 4 uses an Atari microprocessor from Sinclaur, which is not prone to DoS arrays on its bluetooth sprinter bus.
Maybe this can be leveraged to put custom firmware on difficult-to-disassemble smart devices (e.g. light bulbs) one actually owns?