Linux is part of the IoT security problem, dev tells Linux conference

Does that 'thing' really need to run Linux, given alternatives have smaller attack surfaces?

The Mirai botnet? Just the “tip of the iceberg” is how security bods at this week's see the Internet of Things.

Presenting to the Security and Privacy miniconf at, embedded systems developer and consultant Christopher Biggs pointed out that Mirai's focus on building a big DDoS cannon drew attention away from the other risks posed by insecure cameras and digital video recorders.

IoT offers a full suite of risks, he said: a perpetrator could just as easily use badly-secured cameras or recorders to stalk a victim, or download videos for blackmail. There's a huge potential for mass data collection by someone driving around “sniffing for vulnerable devices”, and there's plenty of scope for unauthorised control.

“It might be briefly funny if someone works out subvert autonomous computers into delivering free groceries from Woolworths or free petrol from BP,” Biggs said, but how would you react if your lights started flashing every 200 milliseconds unless you paid Bitcoin to your attacker?

And firewalls fall far short of offering protection, he said, for obvious reasons: they're oriented to block traffic from the outside, and if you haven't turned off UPnP, Things expect to open whatever ports they wish.

As another presenter, Tom Eastman, told the conference: “You're inviting a device into your home or office that you have absolutely no control over. You don't know what threats it enables, and you have no way of updating the software on it.”

Biggs added that “the monsters are inside the room. If IoT devices use cloud services, there's the risk of that service being compromised … many devices on the market are finicky to install, have low-quality user interfaces, and no provision for maintenance.”

The enemy is 'us'

Biggs therefore feels that the enemy is IoT developers who don't think of how real-world users behave when designing connected things, and create devices without upgrade paths.

“Most of the time there's no useful brand identification on the device. If there's a bug, you probably won't know. If you do know, there's probably no patch. And if you complain, there's probably no-one who cares.”

“We as geeks owe it to our friends to design things they can use,” he said.

Biggs emphasised the relative immaturity of the IoT market, something that's clearly evident from his self-defence advice, which is clearly more geek-ready than consumer-ready at this stage.

Too often, he said, there's too much in the Linux stack that device makers build: “It's easy to install a complete Linux distribution on the device and not bother to reduce the threat surface. In fact, sometimes it's arguable that there better choices than Linux for an OS for IoT's simple applications.

“There's no incentive to do better. If the buyer doesn't care, the vendor won't care.”

But defence is hard, as Biggs' “selecting IoT devices” list illustrates:

  • Look for unexpected devices or open Wi-Fi networks you don't recognise;
  • When you see an unexpected device, run a port scan to see what services it's offering;
  • Don't accept devices that ask you to do unacceptable things, such as running untrusted software;
  • Look for devices that support standard protocols or a well-documented API.

Devices that support a well-known framework from the likes of Apple, Google or Amazon (or the open source HomeKit connector, HomeBridge), are only going to open one hole in your firewall, he added.

However, while such things may indicate devices that are a cut above the rubbish, it also demands knowledge that's a cut above the consumer.

The same could be said for his advice that an IoT buyer should create a separate network for those devices, rather than having them all on the same home LAN.

His developer advice sits much more readily with its intended audience:

  • Align with one of the major frameworks – even if Apple is difficult to deal with;
  • Watch the development of open source frameworks. The Open Connectivity Foundation is working on device profiles that define capabilities, based on “the best bits of UPnP and the Service Location Protocol”;
  • Don't restrict configuration to a mobile app. Provide an API of some kind – “people installing thousands of sensors will thank you”;
  • Put a copy of the instructions in the device, because everybody loses the instructions;
  • Decide what the support life of the device is going to be, and commit to supporting it;
  • If there are higher functions that aren't absolutely mandatory for operation, give people a way to turn those off if a vulnerability arises;
  • Remember, “an IoT device is different from a PC – limit what software you put on it.”

This last item, Biggs concedes, is inconvenient for developers.

“Automate around it,” he said. “When you commit code, your system builds a debug, test, production version for each release. Only put the non-necessary tools in the debug version.”

Biggs' complete presentation is in the video below. ®

Youtube Video

Other stories you might like

  • How refactoring code in Safari's WebKit resurrected 'zombie' security bug
    Fixed in 2013, reinstated in 2016, exploited in the wild this year

    A security flaw in Apple's Safari web browser that was patched nine years ago was exploited in the wild again some months ago – a perfect example of a "zombie" vulnerability.

    That's a bug that's been patched, but for whatever reason can be abused all over again on up-to-date systems and devices – or a bug closely related to a patched one.

    In a write-up this month, Maddie Stone, a top researcher on Google's Project Zero team, shared details of a Safari vulnerability that folks realized in January this year was being exploited in the wild. This remote-code-execution flaw could be abused by a specially crafted website, for example, to run spyware on someone's device when viewed in their browser.

    Continue reading
  • EndeavourOS Artemis: Arch Linux, but a bit friendlier
    The Reg FOSS desk takes the latest release, 22.6, for a spin

    EndeavourOS is a rolling-release Linux distro based on Arch Linux. Although the project is relatively new, having started in 2019, it's the successor to an earlier Arch-based distro called Antergos, so it's not quite as immature as its youth might imply. It's a little more vanilla than Antergos was – for instance, it uses the Calamares cross-distro installer.

    EndeavourOS hews more closely to its parent distro than, for example, Manjaro, which we looked at very recently. Unlike Manjaro, it doesn't have its own staging repositories or releases. It installs packages directly from the upstream Arch repositories, using the standard Arch package manager pacman. It also bundles yay to easily fetch packages from the Arch User Repository, AUR. The yay command takes the same switches as pacman does, so if you wanted to install, say, Google Chrome, it's as simple as yay -s google-chrome and a few seconds later, it's done.

    Continue reading
  • Cisco warns of security holes in its security appliances
    Bugs potentially useful for rogue insiders, admin account hijackers

    Cisco has alerted customers to another four vulnerabilities in its products, including a high-severity flaw in its email and web security appliances. 

    The networking giant has issued a patch for that bug, tracked as CVE-2022-20664. The flaw is present in the web management interface of Cisco's Secure Email and Web Manager and Email Security Appliance in both the virtual and hardware appliances. Some earlier versions of both products, we note, have reached end of life, and so the manufacturer won't release fixes; it instead told customers to migrate to a newer version and dump the old.

    This bug received a 7.7 out of 10 CVSS severity score, and Cisco noted that its security team is not aware of any in-the-wild exploitation, so far. That said, given the speed of reverse engineering, that day is likely to come. 

    Continue reading

Biting the hand that feeds IT © 1998–2022