[keisborg]

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]

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]

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]

They do not. They require arbitrary code execution on the main cpu to be used.

[keisborg]

So, they are basically saying that bash is vulnerable to arbitrary command execution?

[unsnap_biceps]

Yes

[red-iron-pine]

why do we believe their documentation, when they didn't list this in the first place?

they're either lying, or failed to disclose details previously.

why do you think they're doing a better job this time around? there may in fact be no serious threat, but now anything and everything is called into question.

[unsnap_biceps]

The bluetooth HCI has a section for Vendor-specific HCI commands that are primarily used for custom hardware initialization on control as well as for debugging purposes. All manufacturers have undocumented commands. It's why the spec allows vendor specific commands.

If you're at the point where an undocumented bit of functionality in a product takes into question the entire company, you must not trust Intel or AMD or Raspberry PI, or all other chip manufacturers. There's nothing malicious here. There's no security issue. It's fully specification compliant. Why are you so concerned?

Frankly, I feel that if you are so concerned, you should work with the specifications to eliminate the vendor specific extensions if you feel their existence is so damning, rather then shitting on a company for following the defined specifications.

[ajross]

> I have a feeling that

The problem is that Tarlogic went full nuclear with "There is a Backdoor in ESP32!!" all over the tech media based on logic that aligns with yours. "They had a feeling."

This is not a backdoor. It is arguably poor security design as one might like it if the BTLE controller was a separate permissions domain. But it isn't, and doesn't have to be, and there isn't even a theoretical vulnerability demonstrated.