Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ESP32 Undocumented Bluetooth Commands: Clearing the Air

developer.espressif.com

Post reply on HN
Print view View original

61–70 of 92 posts

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#61

Post by avianlyric »

spaintech wrote: post #34
u5wbxrc3 wrote: post #23

Earlier quoted context omitted.

As the article states "These undocumented HCI commands cannot be triggered by Bluetooth, radio signals, or over the Internet, unless there is a vulnerability in the application itself or the radio protocols.". Hence I dont think there is any security risk here assuming the application and radio is safe. It differs in a way that the person must have access to the device to flash firmware I believe. In x86 as you descr…

I agree, hence my direct comment of malicious firmware… For me, the open question is, can one still write a malicious firmware on the ESP32 without the non documented opcodes?

What would be the purpose of such firmware? The ESP32 is a complete SoC, the “firmware”, “OS”, and “application” are all the same binary.

So yes you could write a malicious “firmware” without using undocumented commands. But what would be the point? Said firmware already has complete execution privileges on the devices already, with the ability to read any memory it wants to, by virtue of said firmware being literally all the software running on the devices, and owning all of the memory.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#62

Post by solarkraft »

rswail wrote: post #4

In other words, this was a beatup for internet points, not, in any way, an actual security issue.

It kind of was, but I’m happy that it happened because the way it was done (and still is with other vendors) is bad. This resolved that and in my most optimistic dreams other vendors would now follow.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#63

Post by ChrisRR »

atoav wrote: post #10
rswail wrote: post #4

In other words, this was a beatup for internet points, not, in any way, an actual security issue.

If their goal was to get espressif to explain undocumented functionality they reached it. And espressif should have closed that gap without external pressure.

I think their real goal was to gain customers for their security research business

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#64

Post by ChrisRR »

spaintech wrote: post #15

First and foremost, I have no affiliation with any of the authors previously mentioned. However, I would like to pose a question to the community: Is it feasible to exploit these undocumented HCI commands to develop malicious firmware for the ESP32? Such firmware could potentially be designed to respond to over-the-air (OTA) signals, activating these hidden commands to perform unauthorized actions like memory manipul…

It was feasible even without these commands. If you already had code execution on the host then you could've already done what you wanted with the device

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#65

Post by ChrisRR »

vbezhenar wrote: post #30

Those proprietary implementations should not exist. Bluetooth is open protocol and there's no reason to not use open source implementations.

Just because there are open source stacks, doesn't mean the radios implemented in silicon are open source

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#66

Post by aeve890 »

spaintech wrote: post #34
u5wbxrc3 wrote: post #23

Earlier quoted context omitted.

As the article states "These undocumented HCI commands cannot be triggered by Bluetooth, radio signals, or over the Internet, unless there is a vulnerability in the application itself or the radio protocols.". Hence I dont think there is any security risk here assuming the application and radio is safe. It differs in a way that the person must have access to the device to flash firmware I believe. In x86 as you descr…

I agree, hence my direct comment of malicious firmware… For me, the open question is, can one still write a malicious firmware on the ESP32 without the non documented opcodes?

Yes. You can write whatever malicious firmware in a hardware you have physical access, with or without the undocumented opcodes. Not OTA though, unless there's a bug in the radio stack. Is not an open question.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#68

Post by roger_ »

akx wrote: post #55
roger_ wrote: post #49

Earlier quoted context omitted.

Yeah but: > Espressif will provide a fix that removes access to these HCI debug commands Very annoying for researchers and tinkerers who would like to play with those commands.

You left out the important part of that sentence. > Espressif will provide a fix that removes access to these HCI debug commands through a software patch for currently supported ESP-IDF versions ESP-IDF is the "SDK" for these chips – I read that as "you'll get a new function that you call to disable these commands until you reset the chip, to limit attack surface for the rest of your app".

I guess it could either mean “the patch will remove access to those commands” or “the patch will add the ability to disable those commands”.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#69

Post by rickdeckard »

sschueller wrote: post #26
pjc50 wrote: post #18

Earlier quoted context omitted.

> CE also has some regulations regarding this. Which part of CE? One of the ETSI standards?

I don't know the exact standard. I was told this by one of the many people I worked with trying to get my CE. If I recall correctly it may have to do with the new IoT Cyber Resilience Act stuff.

I guess this is more about "if your product has bluetooth functionality, this section of compliance also applies to your product" than "we have regulation on switching off bluetooth"

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#70

Post by akx »

roger_ wrote: post #68
akx wrote: post #55

Earlier quoted context omitted.

You left out the important part of that sentence. > Espressif will provide a fix that removes access to these HCI debug commands through a software patch for currently supported ESP-IDF versions ESP-IDF is the "SDK" for these chips – I read that as "you'll get a new function that you call to disable these commands until you reset the chip, to limit attack surface for the rest of your app".

I guess it could either mean “the patch will remove access to those commands” or “the patch will add the ability to disable those commands”.

The researcher-or-tinkerer who wants to play with these commands can just not upgrade to the newer ESP-IDF. Or update to a newer ESP-IDF, and revert the patch. It's open source. https://github.com/espressif/esp-idf
Post reply on HN