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

41–50 of 92 posts

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#41

Post by tzs »

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…

One fairly common reason to not document something is not wanting to commit to supporting it or to keeping it around in future releases. Document it and customers will come to depend on it and then you might be stuck with it.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#42

Post by akimbostrawman »

rollcat wrote: post #38
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?

>How much more do you want?

Be open (source) by default to prevent such issues from the start. A pledge does nothing, open code does.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#43

Post by Crosseye_Jack »

looofooo0 wrote: post #36
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.

I've in no way surveyed the whole wifi mcu market. But wasn't the "beginnings" of Espressif in the western world that it was a cheap wifi mcu that was at the time very popular in cheap Chinese wifi enabled products.

The DIY market (at least in the west) came later. I still remember reading the hackaday article about them being discovered back in the day - https://hackaday.com/2014/08/26/new-chip-alert-the-esp8266-w... and back then all the documentation was in Chinese.

I remember a ton of cheap Chinese wifi enabled stuff would come with an esp for a good while, until even cheaper wifi chips hit the market.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#44

Post by nonrandomstring »

numpad0 wrote: post #33
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…

Great example, and I'm old enough to have also wondered why those "nc" pins on valves and ICs clearly did do something.

As you frame it, it's "What the eye doesn't see the heart doesn't grieve". Definitely apropos the making of burgers and sausages.

Now we have a different discussion, about "internal" or "external" legibility.

We used to live in a world of high trust in vendors. Those days are gone. Vendor malware is a massive and growing problem and supply-chain legibility is a hot topic.

FWIW I'm arguing the fully open position. Unless you've desperate trade secrets, there is no "internal". And if you've a 16 bit register that's 65536 entries, most of them sparsely documented as "no op". And if a researcher finds it does something,... it's suspicious by default.

This "no user serviceable parts" is an old schism in technology. Today we have almost blanket rights to repair and openness is the new security model.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#45

Post by IshKebab »

dengjiuhong wrote: post #21

Yet, a significant number of stock investors still suffer heavy losses because the market gets rattled by these exaggerated, attention-grabbing headlines. While the consensus here rightly labels this a non-issue—debug commands, not a backdoor, with no remote exploit possible—the sensationalism still has real-world impact. It’s frustrating to see how security hype, often just for internet clout or CVEs as pointed out,…

Their stock price hasn't changed significantly with this news.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#46

Post by looofooo0 »

Crosseye_Jack wrote: post #43
looofooo0 wrote: post #36

Earlier quoted context omitted.

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.

I've in no way surveyed the whole wifi mcu market. But wasn't the "beginnings" of Espressif in the western world that it was a cheap wifi mcu that was at the time very popular in cheap Chinese wifi enabled products. The DIY market (at least in the west) came later. I still remember reading the hackaday article about them being discovered back in the day - https://hackaday.com/2014/08/26/new-chip-alert-the-esp8266-w..…

I think they made it DIY friendly in China first.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#47

Post by swyx »

looofooo0 wrote: post #36
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.

actually how large are they? i believe ESP32 has a huge market share of a small market and i'm curious how you build a business like this

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#48

Post by vbezhenar »

rollcat wrote: post #38
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?

I think that they handled this particular issue well. It was more rant about general state of things in the industry. I worked with Nordic chips and they also supply enormous 120 KB proprietary blob called SoftDevice which you supposed to put into your firmware and let it own all the interrupts. This is terrible experience.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#49

Post by roger_ »

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.

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.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#50

Post by 1oooqooq »

rswail wrote: post #4

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

How you think always-open debug is NOT a security issue?

The blog post is a "nothing to see here". You really fell for it? Do we still do car analogies? Here's this car with just a ignition button without keys, and keys to your home in the glovebox and the address already on the GPS... but the thief would have to break into the car first!

Post reply on HN