Undocumented backdoor found in ESP32
-
smokeymike32
- Posts: 4
- Joined: Tue Jan 02, 2024 10:18 pm
Undocumented backdoor found in ESP32
"In total, they found 29 undocumented commands, collectively characterized as a "backdoor," that could be used for memory manipulation (read/write RAM and Flash), MAC address spoofing (device impersonation), and LMP/LLCP packet injection."
"Espressif has not publicly documented these commands, so either they weren't meant to be accessible, or they were left in by mistake."
https://www.bleepingcomputer.com/news/s ... n-devices/
https://www.tarlogic.com/news/backdoor- ... t-devices/
"Espressif has not publicly documented these commands, so either they weren't meant to be accessible, or they were left in by mistake."
https://www.bleepingcomputer.com/news/s ... n-devices/
https://www.tarlogic.com/news/backdoor- ... t-devices/
-
kevinevans
- Posts: 24
- Joined: Thu Aug 25, 2022 10:34 pm
Re: Undocumented backdoor found in ESP32
Is this in ESP-IDF or is it in an underlying component or HW? Can't quite tell
-
MicroController
- Posts: 2661
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: Undocumented backdoor found in ESP32
The command table they found seems to reside in ROM. But from their slides I cannot deduce if this is a viable attack vector. After all, besides the existence of a table in ROM the slides don't show much. They don't even state if the attack code on the PC actually achieves anything on the ESP, or the ESP firmware they used, or the chip/ROM version. Mucho left to be desired in order to assess the severity...
Guess we'll have to wait for a statement from Espressif. Because, of course, the folks at Tarlogic informed Espressif of the vulnerabilities they found before making them public, right?
Guess we'll have to wait for a statement from Espressif. Because, of course, the folks at Tarlogic informed Espressif of the vulnerabilities they found before making them public, right?
Re: Undocumented backdoor found in ESP32
I'm not going to accuse the obvious here, given that altruism is the most logical reason for providing so much (crippled) value for so little price, stressing to make everything but the most sensitive part of the logic open-source & verifiable.
Likewise I'm just as eager to get my hands on the brand new & very powerful upcoming esp32-p4's (disclosed) "errata".
Likewise I'm just as eager to get my hands on the brand new & very powerful upcoming esp32-p4's (disclosed) "errata".
Re: Undocumented backdoor found in ESP32
From what I can tell (and note that while I work for Espressif, at the moment I only have access to the slides, no internal information on this particular issue) is that they found a bunch of debug commands in the HCI interface that allow for, amongst others, reading/writing flash and ram.
The HCI interface is used as an interface between the low-level BT layers and the main BT stack (in ESP-IDF, the main stack would be Bluedroid or NimBLE.) So for 99.99% of the use cases, this set of debug commands offers no extra functionality: if you can control the HCI interface, you already have (privileged) code running on the ESP32 and you can already write to flash/RAM using existing functionality; you don't need to hijack the HCI interface for that. I can imagine there's a small number of applications which tunnel the ESP32s HCI over serial to a host computer or secondary microcontroller to run the main BT stack there. In that case, it means that an attacker who can compromise the host computer or secondary uC can also compromise the ESP32.
From what I estimate, for the small number of devices in the 2nd category, this is fixable pretty easily: while the commands themselves exist in ROM, there is no direct method in ROM to access the HCI interface from outside the ESP32. It's trivial to update ESP-IDF to insert a small stub that filters out any of the debug commands, blocking any outside attempt to use them. Affected devices are then one firmware update away from being free of this issue. Also note that for all I know, we may already do this: while the slides mention the existence of the issue, I don't see a proof-of-concept anywhere.
In other words: This is something we'll likely patch out in an ESP-IDF update, as there's no real use for this debug interface in production devices. However, this is not something that impacts security at all in the vast majority of ESP32 applications, and in the small number of remaining cases, certainly not something that is exploitable on its own.
The HCI interface is used as an interface between the low-level BT layers and the main BT stack (in ESP-IDF, the main stack would be Bluedroid or NimBLE.) So for 99.99% of the use cases, this set of debug commands offers no extra functionality: if you can control the HCI interface, you already have (privileged) code running on the ESP32 and you can already write to flash/RAM using existing functionality; you don't need to hijack the HCI interface for that. I can imagine there's a small number of applications which tunnel the ESP32s HCI over serial to a host computer or secondary microcontroller to run the main BT stack there. In that case, it means that an attacker who can compromise the host computer or secondary uC can also compromise the ESP32.
From what I estimate, for the small number of devices in the 2nd category, this is fixable pretty easily: while the commands themselves exist in ROM, there is no direct method in ROM to access the HCI interface from outside the ESP32. It's trivial to update ESP-IDF to insert a small stub that filters out any of the debug commands, blocking any outside attempt to use them. Affected devices are then one firmware update away from being free of this issue. Also note that for all I know, we may already do this: while the slides mention the existence of the issue, I don't see a proof-of-concept anywhere.
In other words: This is something we'll likely patch out in an ESP-IDF update, as there's no real use for this debug interface in production devices. However, this is not something that impacts security at all in the vast majority of ESP32 applications, and in the small number of remaining cases, certainly not something that is exploitable on its own.
Re: Undocumented backdoor found in ESP32
Hi Folks
The vulnerability description is as follows: Espressif ESP32 ICs contain 29 hidden Bluetooth HCl commands, such as "0xFC02" – "Write memory" (CVE-2025-27840, CVE-2025-27840, CVSS 6.8, risk"medium"). The undocumented commands allow attackers to manipulate memory and even ultimately flash and thus take complete control.
CVE-2025-27840
Pascal Gujer wrote on x
"ESP32 “backdoor”? Not so fast. Yes, hidden HCI commands allow deep access to memory, flash, and Bluetooth internals. BUT:
Not remotely exploitable via Bluetooth
Not an OTA attack
✔ Requires wired HCI access
✔ Requires high privileges on controller
It’s a post-exploitation tool, not an instant game-over.
If an attacker already controls the host device, you’re cooked anyway.
Hype ≠ Reality."
best wishes
The vulnerability description is as follows: Espressif ESP32 ICs contain 29 hidden Bluetooth HCl commands, such as "0xFC02" – "Write memory" (CVE-2025-27840, CVE-2025-27840, CVSS 6.8, risk"medium"). The undocumented commands allow attackers to manipulate memory and even ultimately flash and thus take complete control.
CVE-2025-27840
Pascal Gujer wrote on x
"ESP32 “backdoor”? Not so fast. Yes, hidden HCI commands allow deep access to memory, flash, and Bluetooth internals. BUT:
✔ Requires wired HCI access
✔ Requires high privileges on controller
It’s a post-exploitation tool, not an instant game-over.
If an attacker already controls the host device, you’re cooked anyway.
Hype ≠ Reality."
best wishes
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
-
MicroController
- Posts: 2661
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: Undocumented backdoor found in ESP32
Thanks for clarifying.
So just a marketing stunt by Tarlogic trying to sell their Bluetooth driver software - purely accidentally implying that "billions of Espressif IoT chips" in the field are security compromised in the process
So just a marketing stunt by Tarlogic trying to sell their Bluetooth driver software - purely accidentally implying that "billions of Espressif IoT chips" in the field are security compromised in the process
Who is online
Users browsing this forum: PetalBot and 10 guests
