[haswell]

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.

[iracigt]

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.

[Purplish9893]

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.

[haswell]

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.

[huang_chung]

> 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

[unsnap_biceps]

If you need local access to enable remote access, it's not a RCE.

[mystified5016]

The exploit here is that you can reprogram new firmware onto the device.

The reason it's not important is that you require a physical connection to the target device. The exact same type of connection you use to program firmware in the first place.

The "backdoor" is just that there's now one additional way to program firmware with a physical connection to the chip. The only issue is it was never documented.

There's no potential for exploitation here. If you have physical access to a real serial port on one of these chips, you cab load your own firmware. That's it. That's the entire exploit.

It's meaningless nothing. It really only matters at all if you care about blocking unauthorized firmware updates over a wired serial connection. If you do care, there are options aplenty.