Security Embedded is 12+ years of experience in building secure systems. Learn more about how we can help you by exploring Phil's blog or contacting us.

Do you need an OS?

A recent project took me through the world of smart plugs available on the market today. These smart plug devices are like any so-called IoT devices. They need headless provisioning of wireless network attributes. The device gives you measurement of power consumption. You can turn it off and on from a connected app on your phone.

I started looking in-depth at one of these devices, and found something surprising. The smart plug in question has an Atheros AR9331 SoC. The Atheros part is well integrated, to say the least. There's 802.11n, 5 ethernet ports, lots of flash interfaces, USB and plenty of GPIOs. Who wouldn't love it?

The thing is, when you start looking at devices like this, life gets complicated. This is a full-fledged MIPS 24k CPU, with most of what an SGI O2 had 20 years ago. There's 64MB of RAM, 8MB of flash, more than enough space for... Linux?!

Use the Board Support Package

When you pick an SoC or MCU for a project, you're getting more than just the silicon. This usually comes with support from the vendor to get your device up and running, including an SDK of some sort. Even Cortex M3-based MCUs are getting more and more complex, looking like SoCs of yore. An SDK is the only way to guarantee reasonable time-to-market for products built on the MCU.

Our 88MC200-based device from some previous blog posts uses Marvell's WSDK. This is a FreeRTOS-based distribution. There's LWIP mixed in there for Layers 3 and down. There's also an entire 802.11n stack in there too.

Wireless networking technology has evolved in the last 15-20 years. The physical layer has become a marvel of its own. Encoding is not trivial, and a lot of what an 802.11n driver does is starting to look a lot more like SDR*. You don't want to build that from scratch. It's expensive, involved, and you need domain-specific expertise to get it right.

Back to the Plug

What I found staggering about all this is that the plug has 3 functions:

  • Turn the device on.
  • Turn the device off.
  • Measuring power consumption at the plug.

The vendor also has baked in a bunch of time-based device control functions, too. A sort of cron for your power outlet, I guess, to convince people you're home when you're not. But still, with all this, there's a full Linux 2.6.31 kernel running in there. There's a 6.1MB SquashFS filesystem, too.

I was wondering where the intersection between simplicity, pragmatism and overkill lies. I think they picked the wrong part: this is a wireless SoC made for access points. Maybe they picked the part before other wireless MCUs existed. If I was to make something like this today, I'd pick the venerable Espressif ESP8266. It's simple, has all the I/O features you need and, oh yeah, comes with an easy to use SDK. Plus it's dirt cheap. With careful engineering, you can attempt to limit your attack surface.

A while ago we discussed how everyone in the product engineering lifecycle is liable for device security. This is an example of the product owner, or maybe a hardware engineer, failed the team. They picked a a part that is complete overkill. When I see this, it's usually due to underspecification of the product. By underspecifying (or 'leaving open product opportunities'), you create risk. You don't want to limit the potential of your device. But you should defining some scope, if only for business reasons. If your engineers are so unsure about the scope that they pick a powerful SoC and a full-fledged OS, you have problems.

Running Linux is always a risk factor for a device like this. The attack surface for the kernel is enormous. All the logic for this device lives in one large static binary. Sounds somewhat like an MCU RTOS image. I'm sure there are gems lurking in that binary, but another day, another AES key...


The only interesting remote access feature for this device: a telnetd. But getting it running is a subject for another blog post. And oh yeah, the root password is `media`. Took about 15 seconds with JTR to figure that one out...

* OK, it's not quite 100% SDR, but seeing things like spectrum analyzers people build out of Atheros radios is pretty cool.

There's No Security Without Entropy

Malloc is an Antipattern