7 ms·

Espressif's Response to Undocumented Commands in ESP32 Bluetooth by Tarlogic

85 points by flockonus 2y ago

unsnap_biceps 2y ago
Previously discussed https://news.ycombinator.com/item?id=43330331 https://news.ycombinator.com/item?id=43330331
ajross 2y ago
That'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-clearing-the-air/ https://developer.espressif.com/blog/2025/03/esp32-bluetooth...
- runjake 2y 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-infect-ot-devices/ https://www.tarlogic.com/news/hidden-feature-esp32-chip-infe...
- ixau 2y ago
  One 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 2y ago
    Why 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 2y ago
      why does a supply chain attack matter? ITT we don't understand supply chains. let's ask a few Hezbollah types about their pagers...
      - ajross 2y ago
        You're not responding to the full statement. Grandparent was saying that a supply chain attack is not possible with this exploit ("exploit", I guess -- again there's no security boundary being crossed here), not that supply chain attacks don't matter in the abstract.
  - ajross 2y ago
    There 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.
spogbiper 2y ago
I 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 2y ago
  The 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 2y ago
    I 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".
- sshine 2y ago
  I'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!
pipe01 2y ago
It's crazy that this got as much attention in the first place
- SV_BubbleTime 2y ago
  Is 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?
  - unsnap_biceps 2y ago
    There'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 2y ago
      You 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.
  - wolrah 2y 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.
altairprime 2y ago
https://developer.espressif.com/blog/2025/03/esp32-bluetooth-clearing-the-air/ https://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
keisborg 2y ago
It 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 2y ago
  https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/flash-encryption.html https://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 2y ago
    I 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 2y ago
      They do not. They require arbitrary code execution on the main cpu to be used.
      - keisborg 2y ago
        So, they are basically saying that bash is vulnerable to arbitrary command execution?
        2y ago
gblargg 2y ago
This 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).
deleted 2y ago
[deleted]
cytocync 2y ago
[dead]

85 points by flockonus 2y ago

Previously discussed https://news.ycombinator.com/item?id=43330331 https://news.ycombinator.com/item?id=43330331

That'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-clearing-the-air/ https://developer.espressif.com/blog/2025/03/esp32-bluetooth...

runjake 2y 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-infect-ot-devices/ https://www.tarlogic.com/news/hidden-feature-esp32-chip-infe...
ixau 2y ago
One 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 2y ago
  Why 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 2y ago
    why does a supply chain attack matter? ITT we don't understand supply chains. let's ask a few Hezbollah types about their pagers...
    - ajross 2y ago
      You're not responding to the full statement. Grandparent was saying that a supply chain attack is not possible with this exploit ("exploit", I guess -- again there's no security boundary being crossed here), not that supply chain attacks don't matter in the abstract.
- ajross 2y ago
  There 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.

spogbiper 2y ago

I 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 2y ago
The 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 2y ago
  I 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".
sshine 2y ago
I'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!

pipe01 2y ago

It's crazy that this got as much attention in the first place

SV_BubbleTime 2y ago
Is 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?
- unsnap_biceps 2y ago
  There'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 2y ago
    You 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.
- wolrah 2y 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.

altairprime 2y ago

https://developer.espressif.com/blog/2025/03/esp32-bluetooth-clearing-the-air/ https://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

keisborg 2y ago

It 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 2y ago
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/flash-encryption.html https://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 2y ago
  I 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 2y ago
    They do not. They require arbitrary code execution on the main cpu to be used.
    - keisborg 2y ago
      So, they are basically saying that bash is vulnerable to arbitrary command execution?
      - 2y ago

gblargg 2y ago

This 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).

deleted 2y ago

[deleted]

cytocync 2y ago

[dead]