Entries Tagged ‘USB’

When and how much should embedded developers implement robust defenses against malicious software in their designs?

Wednesday, September 29th, 2010 by Robert Cravotta

It is easy to believe that malware, malicious software designed to secretly access a system without the owner’s informed consent, only affects computers. However, as more devices support connection with other devices through a USB port, malware is able to hide and launch itself from all types of devices. For example, earlier this year, Olympus shipped over 1700 units of their Stylus Tough 6010 digital compact camera with an unexpected bonus – the camera’s internal memory was carrying an autorun worm that could infect a user’s Windows computer when they connected the camera to it.

Another example of malware using a USB device as a transport and infection mechanism involves USB sticks that IBM handed out at this year’s AusCERT (Australian Computer Emergency Response Team) conference on the Gold Coast, Queensland. In this case, the USB carried two pieces of malware and was handed out at a conference that focuses on Information Security.

Researchers at Stanford’s Computer Security Lab identify that many low cost devices, such as webcams, printers, and other devices that ship with embedded web interfaces, are not designed to withstand malware attacks despite interfacing with the most sensitive parts of a computer network. According to the researchers, NAS (network-attached storage) devices pose the highest risk because they are susceptible to all five of the attack classes the researchers considered in their study.

There are other examples of companies selling infected end products to users. My key concern is that so many devices are sold at such low margins already that it is unlikely the designs include much attention to withstanding malicious software planting themselves in those devices.

The question is, how much energy and attention should embedded designers give to hardening their designs to stopping malicious software – or being an unintended transport for malicious software? I’m not sure an isolated incident that involves using an infected test computer (such as the Olympus example), which infects the end products during the test, is a basis for changing the design flow other than to ensure the test equipment is not itself infected. How would you, or do you, determine how much effort to put into your embedded design to address malicious software from using your system in an unintended fashion?