The Internet of Things is completely reliant on software; the clue is in the name. After all, if the device can’t talk to the web, it can’t provide a service to the web – whether that is status data or control functionality. But the recent iOS 8.0.1 and Shellshock bugs have shown – as well as the ever-lingering Heartbleed – that IoT deployments are only ever 1 dodgy line of code away from death or major vulnerability; and that is a major problem for devices which are meant to be left in the wild for multiple years.
So what are the issues involved? In the past week, the most prominent instance in the media has been Apple’s iOS 8.0.1 update fiasco, despite the much more serious ramifications of the Shellshock bug that affects almost all servers using the BASH functionality in Linux.
The world woke up to Shellshock on September 25th, and thanks largely to the frenzy of reporting that surrounded the somewhat similar Heartbleed exploit, the news of the vulnerability swept through the tech industry over the course of a day. That frenzy has now largely died down, but the scare certainly justified the hype.
The bug was a security hole found in nearly all Linux distributions, which researchers discovered could be used to issue commands to a system using certain HTTP requests and scripts. The CVE-2014-6271 bug caused such a panic because BASH has been used for decades on the assumption it was iron-clad.
And while the bug turned out to be something of a damp squib, with Akamai reporting that 80% of the exploits it had blocked were in fact research tests and no headline exploits reported, the Shellshock fiasco shows the potential for disaster when you operate on assumptions – and that is in organizations with dedicated IT departments, and not at all like the smart home that will have to be diagnosed and troubleshot by the average consumer.
But of course you can’t avoid operating on assumptions. So you need to have a really solid set of plans B through F, just in case something like this happens to a product or service – with manual overrides and battery backups aplenty. Redundancy and patching faults are key in this regard. But it won’t protect you from something like Shellshock, which is pervasive enough to affect all software written using BASH scripts, and therefore billions of connected devices, including those in the IoT – and what if you’ve deployed a device that you can’t patch remotely? That leaves the door open to a smart home, and the homeowner has no realistic way of closing it without removing their connected devices entirely.
And this is before you consider the intertwined nature of consumer products in a smart home. The iOS 8.0.1 update was meant to address some of the launch-day bugs inherent in iOS 8.0.0 – including the fault that meant Apple had to pull its much-vaunted Health app and associated apps from its store. The slightly bungled launch was decidedly un-Apple, and something of a dark day for CEO Tim Cook’s first full product launch, but if one of the largest tech companies in the world can release a bug-fix that bricks cellular radios and kills the fingerprint scanners in its phones, evidently that potential exists for every company – even the ones with gargantuan staffing budgets that should be able to afford the best of the best (and then ignore their cries for extended deadlines no doubt, although we’ll leave speculation about internal affairs for others to tackle more fully).
So if a dodgy Apple update renders the phone unusable, a home owner might lose their primary interaction-device with their automated system. If an update knocks out a hub or a gateway, are there redundant systems in place to carry on in its absence or is the entire connected home going to keel over in its wake?
These issues are inherent in a system which uses third parties, and is perhaps the only argument in favor of protecting a secure and proprietary system – until, that is, you consider that Apple enjoyed a closed ecosystem and still managed to screw up. So how exactly do you go about ensuring that no third party app or product can bring down the smart home?
Well the easiest answer is to pay more attention to the product, despite how incompatible that might be with certain business models and profit margins. So many of the zero-day issues appear to be preventable with more thorough quality control and closer attention paid to seemingly obvious factors – such as using appallingly obvious default passwords which allow attackers to compromise a WiFi network, a la LIFX’s smart bulbs and subsequent forced firmware update.
Another thing to pay close attention to is the position of the device inside a wider ecosystem. How will your connected door lock hold up in the next generation of WiFi, or if your licensing agreement with a vendor expires. Will your device still work if you have to close down, or are you planning on leaving thousands of unsupported devices out in the wild until they die? Will that set you up for a particularly nasty lawsuit?