Hacker News Reader

Comment by rswail | Hacker News Reader

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

Well it was very clear from the beginning that these were a set of debug commands. A back door would probably have a door knocking semantics and a very limited apparent surface. These were direct memory reading and writing command and were available in a standardized protocol.

I would think the real issue was wether they were closed enough in real world design to avoid a security issue through debug means.

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.

Fwiw I’m referring to “trusted” as a specific use case using specific features. Most users won’t use those features. For those that do, this is a big game over. Although some do this, the platform was never well suited to it anyways.

I think we both agree, this “vulnerability” is overstated.

Unfortunately, all too common in the security field.

It's almost the entire field these days - just trying to get CVEs for the CV.

The days of Metasploit 0-days are over, so now it's just loads of sensationalist reporting and box-ticking regulation in companies.

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.

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.

If their goal was to get espressif to explain undocumented functionality they reached it.

And espressif should have closed that gap without external pressure.

If the researchers had written articles and held talks about undocumented HCI commands to gain direct access to the chip, and hammered on the security impact of having such undocumented commands, they could've probably achieved the same thing without resorting to lying.

> Researchers Miguel Tarascó Acuña and Antonio Vázquez Blanco of Tarlogic Security, who presented their findings yesterday at RootedCON in Madrid.

> "Tarlogic Security has detected a backdoor in the ESP32, a microcontroller that enables WiFi and Bluetooth connection and is present in millions of mass-market IoT devices

I'd like to believe the didn't have ulterior reasons to cry "backdoor" knowing that's not the case. That would be a huge indictment of the researchers' characters.

They wanted the spotlight and calling something a "backdoor in a chip used by a billion devices" does the job.

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

> And espressif should have closed that gap without external pressure.

There is a possibility it did not cross their minds that those instructions could an issue.

In their blog post they were very open about what does commands do and it looks like some of their clients that do advanced things with their chips are also aware of the instructions.

Probably the idea that the company is Chinese was enough to not bother asking the manufacturer for documentation about the instructions.

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.

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.

There's nothing to "fall for". Do you have specific evidence that refutes Espressif's rationale for why they believe it's not a security issue. No, a flawed car analogy doesn't count.

If you can break into the application running on an ESP32, you already have full access to RAM etc. The debug HCI commands will not give you any extra access.

Yes, security researchers are incentivized to make issues seem like more of a problem than they are, and vendors are incentivized to minimize them. In this case, though, the reality is much closer to Espressif's version.

I'm old school. I know those boards won't run virtualized unsafe code* but I still like to know what can fiddle with memory behind my back.

* as we assumed with sbcs like raspberypi earlier...

No, the analogy would be storing a key to your house in a box inside your house. You're already inside the house, you don't need the keys.

Reply on news.ycombinator.com