Hi all! Recently I was contacted by a security researcher, Simon Wörner. He had discovered several issues in Mbed OS’s Cordio BLE stack, and spent over a year trying to get in touch with someone at ARM who could handle these issues. However, they did not take any action to fix the issues, so he contacted me shortly before the release of the official CVEs. A total of six CVEs have been published:
All of these relate to the Cordio BLE stack’s HCI parser, which is the component that decodes and processes data from a Bluetooth chip.
For some background, a bluetooth chip, such as an ST BlueNRG module or the second core in an MCU like the STM32WB55, talks to Bluetooth devices over the radio, then sends events to the Mbed MCU in a standard serialized format. This format is called Host Client Interface (HCI) and is what is implemented in the Cordio stack. The parser for incoming HCI messages was tested and found to have several issues.
I am not a security researcher, nor am I very knowledgeable about Bluetooth. However, from what I can understand, all of these vulnerabilities are memory corruption and out-of-bounds errors. Some can “just” be used to crash the system, but several of the vulnerabilities allow arbitrary writes to memory. This means that an attacker with the ability to send arbitrary HCI packets to the Mbed device could manipulate the contents of its memory and could even execute code and take over the device unless the MPU is configured to block executing out of writable RAM.
The good news is that, as far as I’m aware, you cannot simply send arbitrary HCI packets by sending radio packets using another Bluetooth device. Instead, you would need to very carefully craft your Bluetooth radio packets such that the HCI packets they generate cause the bugs to happen. I am unsure if this is possible – it might be, but it certainly seems difficult. The other option would be a physical attack by rewiring the PCB and injecting packets into the serial connections between the Mbed device and the Bluetooth module, in cases where an external module is used. This would of course require physical access to the device, but could be used for things like circumventing code read protections.
Thanks to hard work by @Diff-fusion, @chris-snow, and @fireknight-hJ on GitHub, all of these issues have now been fixed in the master branch of Mbed CE. However, they remain unfixed in ARM Mbed 6, as this repo has virtually stopped accepting PRs. If you use Mbed 6 in a commercial device with Bluetooth support, I strongly suggest that you migrate to Mbed CE. Please contact me if there are any issues preventing your migration! Or, if you still wish to use Mbed 6, please apply the patches from the following PRs: (1) (2) (3) (4) (5) (6).
I would also like to like to thank Simon and any other team members at the CISPA Helmholtz Center for Information Security for their help in discovering these issues!