ESP32 Undocumented Bluetooth Commands: Clearing the Air
developer.espressif.com
ESP32 Undocumented Bluetooth Commands: Clearing the Air
1–10 of 92 posts
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#2tl;dr whichever system using an ESP32 as a bluetooth adapter may also just run arbitrary code on the ESP32 itself over the same interface. Commands have to be issued from the host system, not from the air.
This sounds like... a good feature? There are indeed some scenarios where doing so poses a security risk. But most of the time I do want to be able to run arbitrary code on e.g. my WiFi dongle when I'm in control. I know FCC is not a fan of this idea though.
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#3> Espressif will document all Vendor-specific HCI commands to ensure transparancy of what functionality is available at the HCI layer
I'm very glad they're going to be more transparent rather than try to lock things down more. I've been impressed with Espressif over the years and I'm glad they're continuing to impress.
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#4In other words, this was a beatup for internet points, not, in any way, an actual security issue.
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#5In other words, this was a beatup for internet points, not, in any way, an actual security issue.
Well it was very clear from the beginning that these were a set of debug commands. A back door would probably have a door knocking semantics and a very limited apparent surface. These were direct memory reading and writing command and were available in a standardized protocol.
I would think the real issue was wether they were closed enough in real world design to avoid a security issue through debug means.
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#6Related:
Undocumented backdoor found in Bluetooth chip used by a billion devices
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#7Context: https://www.tarlogic.com/news/hidden-feature-esp32-chip-infe...
Both HN discussion [1] and blogs [2] mentioned that it was a nothingburger.
tl;dr: there are undocumented debugging interfaces on the original ESP32 chip that can only be accessed by code running on the microcontroller or via another computer connected via the physical UART interface. No remote exploit possible. Espressif will now provide a patch to disable these debugging interfaces and document all yet-undocumented interfaces.
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#8tl;dr whichever system using an ESP32 as a bluetooth adapter may also just run arbitrary code on the ESP32 itself over the same interface. Commands have to be issued from the host system, not from the air. This sounds like... a good feature? There are indeed some scenarios where doing so poses a security risk. But most of the time I do want to be able to run arbitrary code on e.g. my WiFi dongle when I'm in control.…
Unless you reverse engineer the radio firmware, i dont think you can change the RF front end much
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#9You should be switching off the bluetooth on your device if is not needed. CE also has some regulations regarding this.
I use the ESP32 in my product[1] I am glad they exist. Their per-certified modules save you quite a bit of money when you do your CE testing.
Espressif also offer free design review if you are using their chip in your commercial project/product[2].
[1] https://www.stationdisplay.com/
[2] https://www.espressif.com/en/contact-us/circuit-schematic-pc...
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#10In other words, this was a beatup for internet points, not, in any way, an actual security issue.
If their goal was to get espressif to explain undocumented functionality they reached it.
And espressif should have closed that gap without external pressure.