Hacker News Reader

Comment by fra | Hacker News Reader

First and foremost, this speaks to the ubiquity and hacker friendliness of Espressif's chips. Most of their competitors (I'm looking at you, Broadcom), prefer security through obscurity and make it extremely difficult to get access to chips, let alone SDKs. I am certain that similar vulnerability exist in every embedded WiFi chipset out there.

That being said, the status quo is completely untenable. Connectivity has become the norm in the hardware space, and it is built on a shoddy software foundation. Vendor SDKs are often best effort endeavors provided "as is" with no thought given to security or reliability. The results are clear: "the S in IOT stands for security" has become a trope, and connected cameras, locks, washing machines, and many more are getting owned on a weekly basis.

This will change, and whoever cracks this nut will be very successful indeed.

View on HN

Uhh, their WiFi implementation is hacked-together old open source code distributed as statically linked binary blobs. And that is just the software part, there isn't much visibility into the silicon side..

Plus they are a Shanghai-based company and can be compelled by the Chinese government to place hardware back doors.

(They are great for makers though, very affordable, lots of features.)

hahaha, this is not a backdoor. It's just logical implementation flaws. If wifi products had good certification, this things wouldn't happen.

Parent didn't say this was a backdoor; just that they "can be compelled" to add one, if requested by the Chinese government in the future.

Sadly this isn't a tin foil hat possibility.

Not unique to Chinese firms either. Sprint resisted blanket surveillance, for a while, and were finally coerced into line. Do you imagine hardware vendors are immune to the same pressure, in the US, Japan, and Europe?

Every hardware manufacturer can be instructed/bribed/forced to add backdoors to their hardware by their own government, hence the necessary push for open drivers/firmware (Broadcom itself, just to name one, has had strong ties with the US govt for a long time). I can imagine a meeting in which some high rank officer says "Here's our backdoor blob, you merge this to all your chipsets firmware, so when necessary we can selectively either shut off Ethernet chips or have them relay information elsewhere as instructed through magic packets, which of course won't be noticed because the leds won't blink and any other chipset seeing these packets will comply as well letting them pass through without allowing any form of sniffing or telling the system administrator (1)". I can't imagine any manufacturer risking their business by replying "nope, we won't comply"; they will jump when commanded to do so and if caught the standard reply will be "we were forced" or "they say it's for national security, you know, to catch those evil terrorists!".

(1) it may seem absurd, sort of sci-fi, but having access to the underlying hardware and its firmware would make it not that hard to do. In that case, the only way to safely analyze network traffic would require very fast logic analyzers that wouldn't use any dedicated network chipsets.

The point is: security through obscurity usually doesn't work well, unless the untrusted party is the hardware maker itself, or whoever decides what they put in the hardware; in that case security through obscurity becomes a lot more about obscurity than security, which makes it near 100% effective.

> Every hardware manufacturer can be instructed/bribed/forced to add backdoors to their hardware by their own government, hence the necessary

This is false. In most western countries governments cant force HW makers to add backdoor.

Portions of the US government have tried multiple times to make the addition of backdoors required via public force of law. They're still trying to promote it now. Short of that public requirement, they can ask & issue orders to not discuss the matter, tie it with defense orders, or imply the withholding of export or trade licenses, all contingent upon cooperation. In the end it looks pretty blurry between a request for cooperation and and order.

Even in China, they might not need to rely on explicit state security authority, just tie it up with state sponsored funding or other softer measures.

> they can ask & issue orders to not discuss the matter,

They can't do that.

Why not in the form of a National Security letter?

https://en.wikipedia.org/wiki/National_security_letter

No, a national security letter can't do this.

It can only compel the release of collected metadata to agencies.

Are holes in security infrastructure required to collect metadata? Are keys, data that secures content - considered metadata? They're not content. Since you can't discuss the letters publicly, a claim could be that it is metadata, and compel keeping the request to collect it as such secret - similarly the fight from the silenced party, if there were any fight, could be out of public visibility.

No they aren't. Read the Wikipedia page you linked to.

It's great that you can make claims like this based on zero evidence or even allegations, but there is no basis in fact for it.

What's more the number of 3rd party people that have to be involved in something like this make it virtually impossible that the national security letter structure could keep them all silent, especially since there are numerous foreign nationals in the supply chains.

Go read the huge amount of ACLU coverage of these, or the many articles linked, or the congressional testimony. There are no allegations that this mechanism is being used to do what you say.

Since when has the US government felt limited by its own laws? The naïveté here is incredible.

That doesn’t prove they have done it. But arguing they can’t is crazy.

Citation needed?

You seem to be making specific, narrow arguments to cast doubt on a much wider claim.

Care to state your belief about the relations between the TLAs and the larger networking and communications firms in the US?

You seem to be making specific, narrow arguments to cast doubt on a much wider claim.

Not the OP, but I think that addressing specific parts of the claim is extremely important.

We've seen this around the PRISM program, where the allegations of support by tech companies were confused by their support for lawful law enforcment warrants (as opposed to the NSA's dragnet surveillance via PRISM). This confusion has reached the point where I saw a lecturer claiming Google helped the NSA collect data as part of PRISM, where the NSA's own slides[1] show the opposite[2].

[1] The famous "smiley slide" https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns... or https://slate.com/technology/2013/10/nsa-muscular-program-sp...

[2] https://arstechnica.com/information-technology/2013/11/googl...

9/11 changed everything.

I would be interested in a review of applicable law which would limit the effect of a US FISA court order.

I'm not aware of anything that would prevent the court from ordering a vendor to implement features to effectuate surveillance ordered by the court.

FISC/FISCR don't order surveillance, they permits it; the only compulsory powers they have are to limit the scope and conditions of the surveillance permitted, and that's binding on the government under FISA, which criminalizes certain surveillance unless authorized by FISC/FISCR.

And that's a pretty weak compulsion, since the people who are bound are the people who would ordinarily prosecute any federal crime, and they probably aren't interested in prosecuting themselves.

FISA courts issue warrants, which are court orders. All US courts have the power of the writ which means they can issue further orders to effectuate an order or ruling. So a court can order a company to assist the government in the execution of a warrant. This is pretty long-settled law.

The fact that some government agent applies for the warrant does not alter the fact that the warrant, once granted, is an order nor does it remove the power of the writ for further orders to effectuate the warrant.

https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill... https://en.wikipedia.org/wiki/Dual_EC_DRBG

> I can't imagine any manufacturer risking their business by replying "nope, we won't comply"

How about the risk to their business when a multinational corporation is X-raying their cores for backdoors (as one does) and finds the state backdoor, and then decides to no longer do business with the hardware manufacturer because of it—and also publicizes the existence of the backdoor, such that other multinationals pull out as well?

(I say "multinationals" because, presumably, purely-domestic corporations could be compelled by the state to accept the backdoor and say nothing about it.)

Has this happened?

Yes. The specific scenario GP described is about SuperMicro and Amazon if my memory is correct on the parties involved.

Edit: it was for sure SuperMicro and Amazon.

https://www.bloomberg.com/news/features/2018-10-04/the-big-h...

That story was widely debunked in followup stories. No one ever demonstrated any of the claims in that story.

I didn’t say it wasn’t debunked, I said that it is what GP was talking about. I didn’t think the “debunked” part was relevant to the question asked that I was responding to. I guess you think it is, so my apologies.

The question asked if it ever happened. That your story didn’t actually happen is most certainly relevant.

Ive looked - a lot - to try and find a reasonable alternative. I haven't found any devices that are as inexpensive and convenient as the ESP chips. Microchip have some relatively inexpensive WiFi modules that need to be used with another MCU and Silabs have some modules including an ARM MCU (WGM160P). These still need blobs but I'm a little happier with a larger more established silicon vendor.

I think (at least a couple of years ago) you could get a dev kit for Microchips parts. The difficulty was then you're responsible for keeping the WiFi stack up to date.

> Plus they are a Shanghai-based company and can be compelled by the Chinese government to place hardware back doors.

Plus Broadcom is a US-based company and can be compelled by the US government to place hardware back doors.

I was going to say...

Espressif have not released the sources of the WiFi implementation, just binaries. I would define that as "security through obscurity".

"avoiding patent infringement lawsuits via opacity"

Has there been any successful patent infringement lawsuits over the last three years that targets a Chinese company that has infringed upon a US company? Isn't that part of the issue in the current trade deal talks with China?

Not a US company being infringed, but Lego has gotten a Chinese court to order Lepin to stop making imitations of Lego products. [1] Since arrests have been made over Lepin not complying [2], it seems like the ruling has teeth.

[1] https://www.brothers-brick.com/2018/11/05/lepin-ordered-to-s...

[2] https://www.brothers-brick.com/2019/04/28/arrests-made-in-le...

Doesn't look like they've actually stopped.

https://lepinworld.com/

Several years ago Scottish chip company FTDI took matters into their own hands by releasing a driver that would brick counterfeits of their USB to serial converter chip: https://en.wikipedia.org/wiki/FTDI#Driver_controversy

And honestly it's a little harder than Broadcom's to reverse. Xtensa doesn't have nearly the same support in reversing tools as ARM and MIPS. On the plus side though you do get unstripped binaries since it's a static library.

I agree, it is for sure harder to reverse, on the other side without releasing the source, it is also much easier to hide in and keep secret vulnerabilities and or zero-days.

While it is true that the core WiFi code is not open source, the ESP-IDF is significantly more open than anything else on the market today.

This is not to say that Espressif is the bee's knees. I personally wouldn't use their hardware in production. But by making their product easily accessible, and much of the source code open, they have made it easier for white hats to raise security issues.

At least they seem to be working on opening parts of the code and have already released the supplicant code for example.

https://github.com/espressif/esp32-wifi-lib/issues/2 https://github.com/espressif/esp-idf/commit/c1396830243b4c8f...

Vulnerabilities in Broadcom/Cypress wifi chips' firmware have been known for a while now:

https://blog.exodusintel.com/2017/07/26/broadpwn/

yes. "Most of their competitors... prefer security through obscurity"

Count Texas Instruments ("TI") in this camp.

For example, Josh Wyatt of TI is proud of TI's "black box" approach to security, and even became a bit defensive about TI's closed source / "you don't need to know" aspects of its security for its CC3220 chips:

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...

Why the F would anyone use these chips, when you can use a garden variety MCU, use a good TLS stack like WolfSSL or BearSSL, and fully control / own what goes into your product?

The fact that Wyatt & co. needed to question in the first place why the stack should be open is disturbing to say the least.

I hope no one seriously relies on any of these products in any secure application. Indeed, many of the vendors in that thread described how they are moving away from the chip due to TI's asinine stance on the issue.

Their "Trusted Root Catalog" is a total fiasco as well. They were one of the AWS IoT launch partners and they apparently repeatedly failed to including AWS root authorities in their catalog. They were responsive in acknowledging, but typically took a month plus to actually update the SDK, (released quarterly,) to address it.

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...

They did finally provide a method to use a custom root CA for SSL a year later, https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/....

They seemingly failed to comprehend why anyone would not want to use TI's chain of trust, that is not manufacturer customizable, on proprietary IoT devices. This was explicitly an issue for code signing as well, as it required obtaining a third-party code signing certificate from any number of CA's instead of using our explicit root CA.

[edit] spelling, clarity

> Vendor SDKs are often best effort endeavors provided "as is" with no thought given to security or reliability.

Having worked for a while with the state of the art of microcontroller internet connectivity I can unfortunately second this. Some vendor SDKs are a mess of copied together source code (e.g. old versions of mbedtls and LWIP libraries), random modifications, no clear integration and often quite a few multithreading and memory issues right out of the box. And that's not even to mention that there are often exists exactly 0 unit-tests.

I really hope the state of this space improves in the future, e.g. through new higher quality stacks. Rust would be a great candidate for these things, since it prevents lots of the issues upfront by refusing to compile. But building better stacks takes a lot of time and effort, and someone would first need to start those invest this.

I agree there is a huge problem with security in IoT and it could be a great startup business for the near future. I met somebody in Redwood City who was working on the security on a hardware level, but I guess they have not been very successful.

Reply on news.ycombinator.com