4 ms·

I'm confused, is it that the bluetooth stack has a few undocumented commands? if these are only accessible to the code already running on the device, I'm not su

I'm confused, is it that the bluetooth stack has a few undocumented commands? if these are only accessible to the code already running on the device, I'm not sure I would call it a backdoor

20after4 2y ago
> "Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections." Yeah this does not sound like a RCE.
- haswell 2y ago
  In what way is what you quoted not describing an RCE? Clearly there are unanswered questions like does this malicious firmware exist? and how likely is it that ESP32s in the wild were shipped with it? But they’re still describing an RCE.
  - iracigt 2y ago
    Because it's not remote. This allows a computer with a Bluetooth adapter to debug and modify its own firmware. This is normal. The potential problem is the interface for this was not documented, and the commands are embedded in the HCI host-to-bluetooth-adapter protocol. Because it's undocumented, software developers on the host may not have considered this in their threat modeling. Firmware updates usually require kernel-level privileges, but HCI does not.
    - haswell 2y ago
      Are you saying that none of the undocumented commands are capable of putting the device into a remotely exploitable state? The fact that it might be necessary to execute these commands locally is separate from the effects of executing those commands and the potential implications for hardware in the wild. A simple example would be a supply chain attack that leverages these commands to compromise what will soon be consumer hardware.
      - Purplish9893 2y ago
        If I run `nc -l 31337 | sh` that puts my system into a remotely exploitable state, but that doesn't mean that nc or sh have RCE vulnerabilities, or that operating systems which allow installing nc and sh have RCE vulnerabilities.
        huang_chung 2y ago
        > If I run `nc -l 31337 | sh` that puts my system into a remotely exploitable state Quick, before someone posts this to Mastodon and gives presentation at security conference with title: Living off the Land: the Hidden Threat Within
        haswell 2y ago
        nc and sh are well known and documented tools. Their existence on a system and running state can be inspected and the implications of various configurations is well understood. If someone just discovered nc in the wild and up to that point it had been unknown, people would put that bit of software in a very different category than the one it exists in today.
      - unsnap_biceps 2y ago
        If you need local access to enable remote access, it's not a RCE.
      - iracigt 2y ago
        The devices are sold as programmable. The supplier loads their own code and has complete control over it. This is an advertised feature. Espressif also releases code that makes it into a Bluetooth adapter with a standard interface. Anyone in the supply chain can change the firmware without these commands. The concern is these commands were undocumented and exposed over an interface usually accessible by applications. The host drvier probably didn't expect this interface could make permanent changes. ESP32 devices not using the Bluetooth adapter firmware are unaffected and already running custom closed source (possibly encrypted) code from the supplier.
      - mystified5016 2y ago
  - 20after4 2y ago
    They say "backdoor might be possible via malicious firmware or rogue Bluetooth connections." Malicious firmware is not a RCE. If you install a malicious firmware you can do all kinds of bad stuff without this undocumented behavior. And "rogue Bluetooth connections" is entirely theoretical. That MIGHT be a RCE, but it is not one. More of a hypothesis. The headline alludes to much more than they have actually demonstrated. I'll change my tune when they demo the exploit code.
iracigt 2y ago
Agreed. This is pretty common and no worse than a firmware update. The potential catch is in-band debugging may not require the same privileges on the host you'd expect from a firmware update. So conceivably your userspace (or worse WebBLE, not sure) program could add some malicious payload that's persistent in the adapter. Tracking beacon that persists through a drive replacement is scary, but not an RCE

I'm confused, is it that the bluetooth stack has a few undocumented commands? if these are only accessible to the code already running on the device, I'm not sure I would call it a backdoor

20after4 2y ago

> "Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections." Yeah this does not sound like a RCE.

haswell 2y ago
In what way is what you quoted not describing an RCE? Clearly there are unanswered questions like does this malicious firmware exist? and how likely is it that ESP32s in the wild were shipped with it? But they’re still describing an RCE.
- iracigt 2y ago
  Because it's not remote. This allows a computer with a Bluetooth adapter to debug and modify its own firmware. This is normal. The potential problem is the interface for this was not documented, and the commands are embedded in the HCI host-to-bluetooth-adapter protocol. Because it's undocumented, software developers on the host may not have considered this in their threat modeling. Firmware updates usually require kernel-level privileges, but HCI does not.
  - haswell 2y ago
    Are you saying that none of the undocumented commands are capable of putting the device into a remotely exploitable state? The fact that it might be necessary to execute these commands locally is separate from the effects of executing those commands and the potential implications for hardware in the wild. A simple example would be a supply chain attack that leverages these commands to compromise what will soon be consumer hardware.
    - Purplish9893 2y ago
      If I run `nc -l 31337 | sh` that puts my system into a remotely exploitable state, but that doesn't mean that nc or sh have RCE vulnerabilities, or that operating systems which allow installing nc and sh have RCE vulnerabilities.
      - huang_chung 2y ago
        > If I run `nc -l 31337 | sh` that puts my system into a remotely exploitable state Quick, before someone posts this to Mastodon and gives presentation at security conference with title: Living off the Land: the Hidden Threat Within
      - haswell 2y ago
        nc and sh are well known and documented tools. Their existence on a system and running state can be inspected and the implications of various configurations is well understood. If someone just discovered nc in the wild and up to that point it had been unknown, people would put that bit of software in a very different category than the one it exists in today.
    - unsnap_biceps 2y ago
      If you need local access to enable remote access, it's not a RCE.
    - iracigt 2y ago
      The devices are sold as programmable. The supplier loads their own code and has complete control over it. This is an advertised feature. Espressif also releases code that makes it into a Bluetooth adapter with a standard interface. Anyone in the supply chain can change the firmware without these commands. The concern is these commands were undocumented and exposed over an interface usually accessible by applications. The host drvier probably didn't expect this interface could make permanent changes. ESP32 devices not using the Bluetooth adapter firmware are unaffected and already running custom closed source (possibly encrypted) code from the supplier.
    - mystified5016 2y ago
- 20after4 2y ago
  They say "backdoor might be possible via malicious firmware or rogue Bluetooth connections." Malicious firmware is not a RCE. If you install a malicious firmware you can do all kinds of bad stuff without this undocumented behavior. And "rogue Bluetooth connections" is entirely theoretical. That MIGHT be a RCE, but it is not one. More of a hypothesis. The headline alludes to much more than they have actually demonstrated. I'll change my tune when they demo the exploit code.

iracigt 2y ago

Agreed. This is pretty common and no worse than a firmware update. The potential catch is in-band debugging may not require the same privileges on the host you'd expect from a firmware update. So conceivably your userspace (or worse WebBLE, not sure) program could add some malicious payload that's persistent in the adapter. Tracking beacon that persists through a drive replacement is scary, but not an RCE