Fullscreen HTML5Med Res (??MB)HTML4

SILICON CHIP www.siliconchip.com.au Publisher/Editor Nicholas Vinen Technical Editor John Clarke, B.E.(Elec.) Technical Staff Jim Rowe, B.A., B.Sc Bao Smith, B.Sc Tim Blythman, B.E., B.Sc Technical Contributor Duraid Madina, B.Sc, M.Sc, PhD Art Director & Production Manager Ross Tester Reader Services Ann Morris Advertising Enquiries Glyn Smith Phone (02) 9939 3295 Mobile 0431 792 293 glyn<at>siliconchip.com.au Regular Contributors Dave Thompson David Maddison B.App.Sc. (Hons 1), PhD, Grad.Dip.Entr.Innov. Geoff Graham Associate Professor Graham Parslow Ian Batty Cartoonist Brendan Akhurst Founding Editor (retired) Leo Simpson, B.Bus., FAICD Silicon Chip is published 12 times a year by Silicon Chip Publications Pty Ltd. ACN 626 922 870. ABN 20 880 526 923. All material is copyright ©. No part of this publication may be reproduced without the written consent of the publisher. Subscription rates (12 issues): $105.00 per year, post paid, in Australia. For overseas rates, see our website or email silicon<at>siliconchip.com.au Editorial office: Unit 1 (up ramp), 234 Harbord Rd, Brookvale, NSW 2100. Postal address: PO Box 139, Collaroy Beach, NSW 2097. Phone (02) 9939 3295. E-mail: silicon<at>siliconchip.com.au ISSN 1030-2662 * Recommended & maximum price only. Printing and Distribution: Editorial Viewpoint IoT is a security nightmare The more I hear about the “Internet of Things” (IoT), the more worried I become about how vulnerable these devices will be to hackers, viruses and worms. Microsoft is a multi-billion-dollar company which employs thousands of experienced programmers, yet we frequently find out about severe vulnerabilities in their software. Many of these allow attackers to take over computers remotely. While these are usually patched soon after they are discovered, there are still plenty of ‘zero-day exploits’ out there. It’s just a constant stream of bad news. And it isn’t just Microsoft. Apple, Linux, Google (Android) and many other vendors and devices have had serious flaws discovered in the last twelve months. If these people can’t make a secure system, how can we expect a smaller operation cranking out millions of internet-connected devices to do better? And how much worse is the situation going to be when, instead of having just a handful of PCs and mobile devices in your home or office, you might have hundreds of devices? To make things worse, many of these will probably have out-of-date software, with no easy way to keep them up to date. And if the vendor has gone out of business, or has stopped supporting that particular device, you’ll be totally out of luck. One particularly breathtaking vulnerability I just found out about (which was discovered in 2017) is called “BlueBorne”. The name indicates that it is an airborne Bluetooth attack. I’m mentioning it now because of the sheer incompetence required for such a vulnerability to exist left me gobsmacked. BlueBorne is thought to have (at least initially) affected more than 8.2 billion (!) devices, and all it requires for an attacker to take over your device is for them to be within Bluetooth range. While most newer systems have fixed this, I bet there are still plenty of affected devices floating around. So, how could a set of related vulnerabilities affect Android, iOS, Linux and Windows devices? After all, most of those systems (perhaps excepting Android and Linux) are written by totally different groups of people. Did they all make the same stupid mistakes? How can a simple communications protocol allow random people to execute code on your device? The root causes of the most serious BlueBorne problems come back to what is now starting to sound like a broken record: stack and buffer overflows. Any code which receives data from a remote location into local memory has to be very carefully written to ensure that the memory buffer is large enough to fit the received data. Otherwise, the excess data can spill over into unexpected memory locations. This can be exploited to remotely inject new code into the software, which can then be used to download and execute more malicious code. That can be prevented by fundamental safeguards like data bounds checking, but it must be used consistently. It is just basic good programming practice. But it seems that whoever was in charge of implementing Bluetooth drivers wasn’t disciplined enough to do this, with the result that gaping holes were created in the devices’ defences. Most recent CPUs and operating system an ‘NX bit’ which helps to reduce the chance such a flaw can be exploited, but it can’t totally prevent buffer overflow attacks. It’s better to avoid having them in the first place. I really hope people writing software for IoT devices can avoid this sort of basic mistake, but I am doubtful. This type of problem is going to be multiplied by the number of different devices deployed. So what can you do about it? Not much, unfortunately. Just try to buy devices from vendors you trust (until they break your trust…), and keep their software up-to-date, or avoid them altogether. Nicholas Vinen 24-26 Lilian Fowler Pl, Marrickville 2204 2 Silicon Chip Australia’s electronics magazine siliconchip.com.au