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

31–40 of 92 posts

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#31

Post by gblargg »

Etheryte wrote: post #20
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…

This would require you to have root access to the thing, at that point you might as well write literally any code you like and not bother with the HCI commands.

Just wait until these security researchers learn about the LDR instruction that malicious software could use to read any memory.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#32

Post by londonembedded »

nonrandomstring wrote: post #24

Storm in a teacup. But it raises an interesting question. Why are these HCI commands "undocumented"? A phrase I hear around security nowadays is "Shadow API" [0, 1] A shadow API is an undocumented one, and it tends to set-off massive alarm bells. The researchers were clearly too keen to make a splash, and that reflects a sad state of wannabeism and hustling for crumbs these days. What exacerbates it is proprietary so…

All of this higher level HCI and API shiz rests (in the embedded world) on a set of registers which are usually documented in the daatsheet. By manipulating these registers, the developer can make the IC do anything it is capable of doing: it is the ultimate API, and there is almost no means in code of making the hardware do anything except by this means. So any 'shadow' API is not really of any consequence in embedded, because it all boils down to these registers, which we can perfectly well view or manipulate.

Espressif, as well as all other manufacturers of such BLE enabled SoCs provide at least some parts of their RF stack as precompiled binary. However, Espressif took the decision to deliberately not publish the registers used at lowest level to configure and command the RF peripheral on the IC. All other manufacturers I am aware of publish these registers, just like all the others. Ultimately this minor obfuscation offers no additional security benefit, nor does it create any security loophole above any that exist on any other chipset.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#33

Post by numpad0 »

nonrandomstring wrote: post #24

Storm in a teacup. But it raises an interesting question. Why are these HCI commands "undocumented"? A phrase I hear around security nowadays is "Shadow API" [0, 1] A shadow API is an undocumented one, and it tends to set-off massive alarm bells. The researchers were clearly too keen to make a splash, and that reflects a sad state of wannabeism and hustling for crumbs these days. What exacerbates it is proprietary so…

I was looking up vacuum tube recently. Apparently there are things called "getter" pins in them that connects to internal material deposition device, used to remove last bits of air out of tube in the manufacturing line. The exact behaviors and operating parameters for those pins are corporate secrets and not documented. Datasheets only mention them as "No Connect" pins that do nothing and has to be disconnected from anything for safe and correct operation of the device. BACKDOOR!!! in an analog vacuum tube.

... everything ever always had factory-use-only interfaces. Manufacturers don't document every bits of everything on public datasheets. Granted, the dynamics of this change if they can be used as backdoors, and those might have to be either disclosed or securely disabled, but "why they exist in the first place" is just nonsensical question; they exist for necessary internal purposes.

That question should be "how should factory use interfaces be handled going forward".

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#34

Post by spaintech »

u5wbxrc3 wrote: post #23
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…

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?

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#35

Post by blitzar »

rswail wrote: post #4

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

The is a disconnect between the people who do actual work on the ground in the world and the internet.

People in the real world report things - people on the internet read 3 out of 4 of the words in the headline and screech hysterically and run around spouting prophecies about the end of the world.

I am a person on the internet.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#36

Post by looofooo0 »

unsnap_biceps wrote: post #3

> Espressif will document all Vendor-specific HCI commands to ensure transparancy of what functionality is available at the HCI layer I'm very glad they're going to be more transparent rather than try to lock things down more. I've been impressed with Espressif over the years and I'm glad they're continuing to impress.

It is a relative small company which is catering the DIY market. To build any substantial user base with industrial applications, I guess their way is to continue to be open and enable people to build DIY stuff and a tiny fraction of these will one day build products with ESP chips inside.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#37

Post by blitzar »

ElectRabbit wrote: post #12
Jochim wrote: post #6

Related: Undocumented backdoor found in Bluetooth chip used by a billion devices https://news.ycombinator.com/item?id=43301369

On the HCI interface. That's not a OTA attack. If an attacker can write raw data the HCI interface you are doomed anyway.

If you have access to the targets computer and their password there is an attack vector where you can feasibly gain access their files.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#38

Post by rollcat »

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.

From TFA:

> The ESP32 series of chips support open-source NimBLE and Bluedroid as Bluetooth host stacks.

The undocumented commands in question (which implement the debug interface) are about to become documented, and Espressif was both transparent in their publication, and pledged for more transparency moving forward.

How much more do you want?

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#40

Post by adrian_b »

nonrandomstring wrote: post #24

Storm in a teacup. But it raises an interesting question. Why are these HCI commands "undocumented"? A phrase I hear around security nowadays is "Shadow API" [0, 1] A shadow API is an undocumented one, and it tends to set-off massive alarm bells. The researchers were clearly too keen to make a splash, and that reflects a sad state of wannabeism and hustling for crumbs these days. What exacerbates it is proprietary so…

All complex devices, like CPUs, GPUs, microcontrollers, have tons of undocumented debug features, without exception.

The only difference between devices is whether such debug features remain accessible to users or they are completely disabled after production.

In this specific case, as well explained in TFA, the debug commands do not really provide any additional exploitable capabilities for a malicious programmer, especially because the Bluetooth controller is already hosted on the same CPU as the potentially malicious application, so if that could use the debug commands it could already do anything it wants, like sending arbitrary Bluetooth packets. The Bluetoth driver also can already do anything it wants on the shared CPU, so if it had bugs or backdoors that can be triggered by received Bluetooth packets the existence of these debug commands does not change anything.

Unlike this case where there is nothing to criticize in the reply of ExpressIf or on what they have done, an example of atrocious handling of the undocumented debug features has been provided by Apple, whose devices had for several years, until the end of 2023, a backdoor created by non-disabled debug registers, which allowed a total bypassing of the memory protection, enabling (in conjunction with some bugs in Apple system libraries) complete remote control of an iPhone, and which has been exploited for the remote and undetectable spying of some iPhone owners (discussed on HN at the time of the public revealing of the CVEs).

Post reply on HN