7 ms·

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 s

by fra 7y ago

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.

gioscarab 7y ago
Espressif have not released the sources of the WiFi implementation, just binaries. I would define that as "security through obscurity".
- joezydeco 7y ago
  "avoiding patent infringement lawsuits via opacity"
  - wysifnwyg 7y ago
    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?
    - CDSlice 7y ago
      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-stop-making-and-selling-lego-imitation-products-by-chinese-court-news/ https://www.brothers-brick.com/2018/11/05/lepin-ordered-to-s... [2] https://www.brothers-brick.com/2019/04/28/arrests-made-in-lepin-raid-over-the-continued-manufacture-of-counterfeit-lego-products-news/ https://www.brothers-brick.com/2019/04/28/arrests-made-in-le...
      - monocasa 7y ago
        Doesn't look like they've actually stopped. https://lepinworld.com/ https://lepinworld.com/
    - jbarham 7y ago
      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 https://en.wikipedia.org/wiki/FTDI#Driver_controversy
- monocasa 7y ago
  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.
  - gioscarab 7y ago
    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.
- fra 7y ago
  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.
- fri_sch 7y ago
  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/esp32-wifi-lib/issues/2 https://github.com/espressif/esp-idf/commit/c1396830243b4c8fbea255a04d8a04ed2cb9f3d7 https://github.com/espressif/esp-idf/commit/c1396830243b4c8f...
  - dbuder 7y ago
    And then they said that users should only buy products with reputably sourced chips, like my mom is opening up her electronics and trying to figure out whether or not the USB to serial chip is a fake or not.
stefan_ 7y ago
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..
- danieldk 7y ago
  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.)
  - mendesgeo 7y ago
    hahaha, this is not a backdoor. It's just logical implementation flaws. If wifi products had good certification, this things wouldn't happen.
    - guiambros 7y ago
      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.
      - ncmncm 7y ago
        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?
  - squarefoot 7y ago
    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.
kees99 7y ago
Vulnerabilities in Broadcom/Cypress wifi chips' firmware have been known for a while now: https://blog.exodusintel.com/2017/07/26/broadpwn/ https://blog.exodusintel.com/2017/07/26/broadpwn/
aledalgrande 7y ago
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.
thr0w__4w4y 7y ago
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/t/432128 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?
- xvector 7y ago
  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.
- jlujan 7y ago
  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/t/650792 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/p/758149/2801182#2801182 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
Matthias247 7y ago
> 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.

by fra 7y ago

gioscarab 7y ago

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

joezydeco 7y ago
"avoiding patent infringement lawsuits via opacity"
- wysifnwyg 7y ago
  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?
  - CDSlice 7y ago
    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-stop-making-and-selling-lego-imitation-products-by-chinese-court-news/ https://www.brothers-brick.com/2018/11/05/lepin-ordered-to-s... [2] https://www.brothers-brick.com/2019/04/28/arrests-made-in-lepin-raid-over-the-continued-manufacture-of-counterfeit-lego-products-news/ https://www.brothers-brick.com/2019/04/28/arrests-made-in-le...
    - monocasa 7y ago
      Doesn't look like they've actually stopped. https://lepinworld.com/ https://lepinworld.com/
  - jbarham 7y ago
    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 https://en.wikipedia.org/wiki/FTDI#Driver_controversy
monocasa 7y ago
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.
- gioscarab 7y ago
  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.
fra 7y ago
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.
fri_sch 7y ago
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/esp32-wifi-lib/issues/2 https://github.com/espressif/esp-idf/commit/c1396830243b4c8fbea255a04d8a04ed2cb9f3d7 https://github.com/espressif/esp-idf/commit/c1396830243b4c8f...
- dbuder 7y ago
  And then they said that users should only buy products with reputably sourced chips, like my mom is opening up her electronics and trying to figure out whether or not the USB to serial chip is a fake or not.

stefan_ 7y ago

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

danieldk 7y ago
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.)
- mendesgeo 7y ago
  hahaha, this is not a backdoor. It's just logical implementation flaws. If wifi products had good certification, this things wouldn't happen.
  - guiambros 7y ago
    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.
    - ncmncm 7y ago
      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?
- squarefoot 7y ago
  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.

kees99 7y ago

Vulnerabilities in Broadcom/Cypress wifi chips' firmware have been known for a while now: https://blog.exodusintel.com/2017/07/26/broadpwn/ https://blog.exodusintel.com/2017/07/26/broadpwn/

aledalgrande 7y ago

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.

thr0w__4w4y 7y ago

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/t/432128 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?

xvector 7y ago
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.
jlujan 7y ago
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/t/650792 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/p/758149/2801182#2801182 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

Matthias247 7y ago

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