In such a system, the ESP32 fully trusts the host. If an attacker maliciously gains control over the host system, they could potentially issue these debug commands to influence ESP32’s behavior. However, an attacker must first compromise the host device, making this a second-stage attack vector rather than a standalone vulnerability. Or, gain a physical access to the device to send the HCI commands over serial interface.
Does this even count as backdoor? Not really if you have to have access to the device in the first place.
It certainly opens up lost of “evil maid” attacks.
An ESP32 is a powerful thing, but it is also a microcontroller.
They are programmable as soon as you have physical access. They are NOT like whole PC’s that you can lock up with passwords etc.
More like a gun that you can fire as soon as you have physical access.
I wonder where the expectation has come from? People seem to think that it should be different than it is.
That’s because the article that started the whole argument tried very hard to present an expected behavior for embedded chips as a security hole.
Does it? The quoted passage is also in reference to a less commonly used configuration, in which it is basically used as a communications coprocessor.
I’m all for embedded stuff having backdoors, it’s what makes it possible to use custom firmware on devices that have otherwise crappy vendor locked firmware.
