Espressif's Response to Undocumented Commands in ESP32 Bluetooth by Tarlogic
85 points by flockonus 4 months ago | 28 comments- spogbiper 4 months agoI know tech reporting has gone downhill, but I was really surprised by how badly this minor issue was overhyped.. articles with titles like "Hidden Backdoor Discovery Could Expose 1 Billion Bluetooth Devices To Hackers" coming out even yesterday. It's a stretch to even call this a back door.
- andrewstuart2 4 months agoThe headlines I saw were irresponsible journalism, plain and simple. There ought to be some significant repercussions or at least apologies and lessons learned posts for those publications and/or authors for crying wolf.
- aruametello 4 months agoI cant say exactly which ones, but the main problem to me is the "second hand news".
probably most news outlets didn't made any research, they just rewrote what the previous outlet published.
as in, "we don't know either, but those guys do!"
so they probably went confident that they weren't wrong with the argument that someone else did the research for them.
i wouldn't dare call them journalists, and it is rather unlikely all of them independently reached the same conclusion that this is a "massive vulnerability".
- aruametello 4 months ago
- sshine 4 months agoI've heard they're programmable. Programmable!
That means you could attach wires to any device and simply overwrite the firmware on them, replacing it with your own. If that's not a severe security vulnerability, I don't know!
- andrewstuart2 4 months ago
- altairprime 4 months agohttps://developer.espressif.com/blog/2025/03/esp32-bluetooth...
This is a more detailed and informative link than the press release above:
> Espressif will provide a fix that removes access to these HCI debug commands through a software patch for currently supported ESP-IDF versions
> Espressif will document all Vendor-specific HCI commands to ensure transparancy of what functionality is available at the HCI layer
- ajross 4 months agoThat's about the right response. These don't expose a command across a security boundary. You can only exercise them if you're already executing arbitary code on the main CPU core.
Honestly the original Tarlogic report was so irresponsible that I have to wonder if Espressif is considering legal action.
Note btw that the linked press release points to the more detailed blog post explaining the architecture: https://developer.espressif.com/blog/2025/03/esp32-bluetooth...
- runjake 4 months ago> I have to wonder if Espressif is considering legal action.
As the article says, they worked with Tarlogic to provide a correction. So, probably not.
https://www.tarlogic.com/news/hidden-feature-esp32-chip-infe...
- ixau 4 months agoOne of the issues here (pointed by the authors) is supply chain attack.
You order 100k chips for your products and while in transit they get compromised by a this party via the said commands
In any case either it is gross incompetence or deliberate malice.
- unsnap_biceps 4 months agoWhy does that matter at all? There's no persistence granted by the debug commands. When you flash it with your firmware, it's clean. If you trust the firmware that ships, they can do arbitrary code in it, so why care about a few debug interfaces?
- red-iron-pine 4 months agowhy does a supply chain attack matter? ITT we don't understand supply chains.
let's ask a few Hezbollah types about their pagers...
- red-iron-pine 4 months ago
- ajross 4 months agoThere was no such attack demonstrated. The debug commands operate on the memory of the running BTLE controller. They can't be used to modify persistent firmware.
- unsnap_biceps 4 months ago
- runjake 4 months ago
- keisborg 4 months agoIt it possible to create firmware that is encrypted and cannot be read out. Espressif state there is no security issues, but I have a feeling that these debug commands may be used to read out the flash of a properly secured esp32 that otherwise would not be possible…
- unsnap_biceps 4 months agohttps://docs.espressif.com/projects/esp-idf/en/stable/esp32/... Doesn't say anything about reading the encrypted flash as being blocked, just that it will be the encrypted contents, same as if you pull the flash chip off and read it.
You need arbitrary code execution on the main cpu to execute the debug commands. Once you have that, it's game over anyway. Why not just post the data to a url rather than trying to smuggle it out in Bluetooth headers? Or just broadcast it via normal Bluetooth packets?
There's no issue here.
- keisborg 4 months agoI would hope so, but on
Tarlogics blog post, it is mentioned “modifying chips arbitrarily”, “infecting chips with malicious code”, “obtain confidential information stored on them”.
Even though they rephrased the backdoor wording, the remaining statements make me believe the undocumented functions can be used to gain code execution on the main cpu.
- unsnap_biceps 4 months agoThey do not. They require arbitrary code execution on the main cpu to be used.
- unsnap_biceps 4 months ago
- red-iron-pine 4 months agowhy do we believe their documentation, when they didn't list this in the first place?
they're either lying, or failed to disclose details previously.
why do you think they're doing a better job this time around? there may in fact be no serious threat, but now anything and everything is called into question.
- unsnap_biceps 4 months agoThe bluetooth HCI has a section for Vendor-specific HCI commands that are primarily used for custom hardware initialization on control as well as for debugging purposes. All manufacturers have undocumented commands. It's why the spec allows vendor specific commands.
If you're at the point where an undocumented bit of functionality in a product takes into question the entire company, you must not trust Intel or AMD or Raspberry PI, or all other chip manufacturers. There's nothing malicious here. There's no security issue. It's fully specification compliant. Why are you so concerned?
Frankly, I feel that if you are so concerned, you should work with the specifications to eliminate the vendor specific extensions if you feel their existence is so damning, rather then shitting on a company for following the defined specifications.
- unsnap_biceps 4 months ago
- keisborg 4 months ago
- ajross 4 months ago> I have a feeling that
The problem is that Tarlogic went full nuclear with "There is a Backdoor in ESP32!!" all over the tech media based on logic that aligns with yours. "They had a feeling."
This is not a backdoor. It is arguably poor security design as one might like it if the BTLE controller was a separate permissions domain. But it isn't, and doesn't have to be, and there isn't even a theoretical vulnerability demonstrated.
- unsnap_biceps 4 months ago
- unsnap_biceps 4 months agoPreviously discussed https://news.ycombinator.com/item?id=43330331
- pipe01 4 months agoIt's crazy that this got as much attention in the first place
- SV_BubbleTime 4 months agoIs it?
A CCP subsidized chip is massively popular for its low cost in the US.
Ok if you feel this is not a backdoor, but the issue is this is not proof. There will never be proof.
There has long been suspicion. How is it crazy that undisclosed “features” are getting attention?
- wolrah 4 months ago> Ok if you feel this is not a backdoor, but the issue is this is not proof. There will never be proof.
When it's a special type of command that's only accessible from the host CPU, I have a hard time seeing any way to call it a backdoor. If it were some weird special input to a common command that could hypothetically be handed untrusted input that'd be a different matter, but in this case it's not going to be getting triggered unless the software running on the host CPU is intentionally trying to activate it.
Could these commands be hypothetically used by a malicious actor who had already managed to compromise the code running on the main CPU? Sure. Is there any reason to believe they're put there specifically to allow some kind of exploitability instead of just being debugging commands? Not a bit.
- unsnap_biceps 4 months agoThere's proof that this isn't a backdoor. There isn't proof that there isn't a backdoor, but that's a wildly different claim then "we found a backdoor".
- SV_BubbleTime 4 months agoYou do not have proof this is not a backdoor. The word proof is being taken too lightly. You don’t get proof in hardware - you get promises.
And the people making them here have been found to break them. The CCP not necessarily Espresif.
- SV_BubbleTime 4 months ago
- wolrah 4 months ago
- SV_BubbleTime 4 months ago
- gblargg 4 months agoThis is more concise and clearer. Their first one mocked them being called undocumented, putting it in quotes, when they were in fact undocumented. The main point is that if malicious software has access to these commands, it has access to the rest of the system already so this is the least of your problems (if I understand this correctly).
- cytocync 4 months ago[dead]
- 4 months ago