4 ms·

It sounds like it might be very useful for an attacker who already attained access via some other exploit. Imagine the ESP32 is being used as a wifi/bluetooth

It sounds like it might be very useful for an attacker who already attained access via some other exploit. Imagine the ESP32 is being used as a wifi/bluetooth "modem" via a serial link to a host system (rather than the ESP32 used as a standalone SOC.) In theory, the attacker could then use the undocumented commands to scan, spoof, or otherwise attack any near by bluetooth devices. Perhaps this could even be achieved without gaining root on the device which is hosting the esp32.

huang_chung 2y ago
> In theory, the attacker could then use the undocumented commands to scan, spoof, or otherwise attack any near by bluetooth devices. So? Device is 0wned. Did you think Bluetooth chip is magic protection device for rest of the network? How would you stop physical external actor? Do you have "No ESP32 permitted on this property" signs on windows?
- 20after4 2y ago
  I'm not arguing that this is a big f'in deal. Seems like it's not much of a deal at all actually.
iracigt 2y ago
Yeah, the research is good. Software developers do not expect HCI to have this type of control. Because it's undocumented, it's not in their threat model and is unexpectedly available from userspace. "Backdoor" isn't wrong, but it is misleading. The threat here is persistence from context that wasn't expected to have this capability.
- seba_dos1 2y ago
  That's right, but... who exposes ESP32's HCI to external world (and not just to another trusted chip) in actual projects? This is the kind of feature you see popping up as a Hackaday article titled "Your ESP32 As A USB Bluetooth Dongle" - you say "neat" and then proceed to forget about it. If you find a device that does it in the wild, then I guess you now gained a nice jailbreaking vector - that is, if it needed jailbreaking at all. Otherwise, it's nothing.
- throwaway5574 2y ago
  > Yeah, the research is good. Software developers do not expect HCI to have this type of control. Because it's undocumented, it's not in their threat model and is unexpectedly available from userspace. This possibility should be obvious to any software developer that knows how modern IO peripheral stacks are constructed. There is little that can be done to defend against a poorly written OS driver that exposes functions like this, even unintentionally, and it is naive to assume that any class of device will lack them unless clearly documented otherwise. This has been of particular concern to developers of open source Linux kernel drivers for decades at this point.
gruez 2y ago
>In theory, the attacker could then use the undocumented commands to scan, spoof, or otherwise attack any near by bluetooth devices. Perhaps this could even be achieved without gaining root on the device which is hosting the esp32. How's this any different than a laptop getting pwned and attackers being able to run aircrack-ng or whatever on it?
- megadata 2y ago
  > How's this any different It's undocumented.
  - gruez 2y ago
    My laptop came with a 10 page quick start guide that mentions nothing about this "vulnerability". The only way to figure out whether a wifi chip can enter promiscuous mode or inject packets is by checking a wiki page maintained by volunteers.
- 20after4 2y ago
  It's not that different. It might be easier than your average "pwn" and might not require root access, but this is only my hypothesis based on what's written in TFA.
  - sitkack 2y ago
    If it is USB, you should be able to do it directly in JS via Chrome.
    - iracigt 2y ago
      WebUSB requires the device to opt in via it's USB descriptors. Otherwise any USB device with firmware updates would have this problem. Maybe an issue here is WebSerial, as HCI comes over a serial port device. I believe the OS should block access to the serial device once the host driver takes it as a Bluetooth adapter though.
tru3_power 2y ago
So why couldn’t one make a malicious iot device/tool to do just that? I’m kinda confused on the need for access via some other exploit. (I have little domain knowledge on Bluetooth) - when you say scan/spoof/attack any near by device, is it ones that the target is already connected to? Sorry for dumb question

huang_chung 2y ago

> In theory, the attacker could then use the undocumented commands to scan, spoof, or otherwise attack any near by bluetooth devices. So? Device is 0wned. Did you think Bluetooth chip is magic protection device for rest of the network? How would you stop physical external actor? Do you have "No ESP32 permitted on this property" signs on windows?

20after4 2y ago
I'm not arguing that this is a big f'in deal. Seems like it's not much of a deal at all actually.

iracigt 2y ago

Yeah, the research is good. Software developers do not expect HCI to have this type of control. Because it's undocumented, it's not in their threat model and is unexpectedly available from userspace. "Backdoor" isn't wrong, but it is misleading. The threat here is persistence from context that wasn't expected to have this capability.

seba_dos1 2y ago
That's right, but... who exposes ESP32's HCI to external world (and not just to another trusted chip) in actual projects? This is the kind of feature you see popping up as a Hackaday article titled "Your ESP32 As A USB Bluetooth Dongle" - you say "neat" and then proceed to forget about it. If you find a device that does it in the wild, then I guess you now gained a nice jailbreaking vector - that is, if it needed jailbreaking at all. Otherwise, it's nothing.
throwaway5574 2y ago
> Yeah, the research is good. Software developers do not expect HCI to have this type of control. Because it's undocumented, it's not in their threat model and is unexpectedly available from userspace. This possibility should be obvious to any software developer that knows how modern IO peripheral stacks are constructed. There is little that can be done to defend against a poorly written OS driver that exposes functions like this, even unintentionally, and it is naive to assume that any class of device will lack them unless clearly documented otherwise. This has been of particular concern to developers of open source Linux kernel drivers for decades at this point.

gruez 2y ago

>In theory, the attacker could then use the undocumented commands to scan, spoof, or otherwise attack any near by bluetooth devices. Perhaps this could even be achieved without gaining root on the device which is hosting the esp32. How's this any different than a laptop getting pwned and attackers being able to run aircrack-ng or whatever on it?

megadata 2y ago
> How's this any different It's undocumented.
- gruez 2y ago
  My laptop came with a 10 page quick start guide that mentions nothing about this "vulnerability". The only way to figure out whether a wifi chip can enter promiscuous mode or inject packets is by checking a wiki page maintained by volunteers.
20after4 2y ago
It's not that different. It might be easier than your average "pwn" and might not require root access, but this is only my hypothesis based on what's written in TFA.
- sitkack 2y ago
  If it is USB, you should be able to do it directly in JS via Chrome.
  - iracigt 2y ago
    WebUSB requires the device to opt in via it's USB descriptors. Otherwise any USB device with firmware updates would have this problem. Maybe an issue here is WebSerial, as HCI comes over a serial port device. I believe the OS should block access to the serial device once the host driver takes it as a Bluetooth adapter though.

tru3_power 2y ago

So why couldn’t one make a malicious iot device/tool to do just that? I’m kinda confused on the need for access via some other exploit. (I have little domain knowledge on Bluetooth) - when you say scan/spoof/attack any near by device, is it ones that the target is already connected to? Sorry for dumb question