Live data from Hacker News

ESP32 Undocumented Bluetooth Commands: Clearing the Air

developer.espressif.com

51–60 of 92 posts

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#51

> 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.

They are in a -lot- of edge devices. They became popular with DIY because they were a very cheap and capable option with the esp8266, which hackers converted from ultracheap UART to WiFi modules into general purpose mcus. They became the DIY default because instead of ignoring this, they embraced it and published specs and translated data sheets. Their diy friendly approach has garnered them a ton of software support and publicity.

They have responded very openly by publishing the vendor specific diagnostic commands.

This whole dog and pony show is very unfortunate, really, since the irresponsible security firm used the term backdoor in a completely inappropriate and misleading way, and the blogosphere and tech press just parroted their claim without bothering to read the disclosure, apparently.

The headlines should have been:

“Security firm Tarlogic makes specious “backdoor” claim at rootCon about popular Bluetooth/Wifi microcontroller deployed in billions of devices.”

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#52
post #47

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.

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

Revenue is now half a Billion Dollar, but they are growing fast.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#53
post #47

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.

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

crunchbase says 500-1000 employees.

They sold 25% of their shares in a 2019 IPO that valued the company at $716m

Market cap is about $3.5b now

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#54

> 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.

> It is a relative small company which is catering the DIY market.

Is that really all it is? I’ve got multiple IOT devices from major vendors that use esp32. I’ve also seen multiple EV chargers that leverage the platform.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#55
post #49

> 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.

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".

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#56
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!

Just like every single car in existence where you can get in and mess with anything inside it?

This analogy makes no sense at all. Once you break into a car, you can quite literally do anything to it. The keys to your home part is simply random.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#57

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,…

At first I thought this smelled like a Targeted PR drive-by, leveraging the distrust of China to intensify anti-China sentiment for political traction. I’ve been quite cynical about this ever since I was exposed to shady PR companies and saw their list of offerings and prices…. But…

Nope. This looks like an irresponsible, hype seeking disclosure by a security firm trying to make a name for itself. Or maybe a really, really good PR firm and a PR savvy security firm, if I put my tinfoil hat on.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#58
post #29
post #4

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

It was both, tbh. These commands would be usable in some attacks against a “trusted” esp32 implementation. It’s something they probably should allow developers to disable but it’s also being WILDLY overstated by clout seekers. You can, from some angles, call this a security flaw or issue. Anyone calling it a backdoor - a term with a specific meaning intentional secret access - is being irresponsible imho

We are talking about a programable device used as a programable device by hobbyists and device manufacturers to make things that you need to program to do something. It’s no different to trying to claim a PC has a security problem because you can load software onto it to do bad things.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#59
post #4

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

There is a narrow set of circumstances where the previously undocumented commands could be exploited by malware running on a host machine or on compromised firmware. It’s kind of a nothing burger because compromise at this level is already pwned and the undocumented commands really don’t add much to that.

What it doesn’t have is a backdoor.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#60
> Espressif will provide a fix that removes access to these HCI debug commands through a software patch for currently supported ESP-IDF versions

> Espressif will document all Vendor-specific HCI commands to ensure transparancy of what functionality is available at the HCI layer

This is great. While this practice may be common and it may not be considered a backdoor, undocumented functionality is definitely a risk. I’m glad that people didn’t just take it as “well that’s how it’s done” but instead are pushing for a better way.

Post reply on HN