If you are involved in the electronics supply chain and are unaware of security vulnerabilities in firmware, you are in for a rude awakening.
Attackers are becoming increasingly aware of how easy it is to hack code in the firmware of peripheral PC devices and embedded systems. Looking for lower-hanging fruit than locked-down PCs, servers, and smartphones, attackers are increasingly taking advantage of exploitable code in the firmware of a wide range of embedded computing devices. These might include printers, modems, motherboards, IP phones, cars or anything else that runs embedded computing apps, such as wearable technology.
Researchers and security experts have demonstrated how these attacks can be used to steal data, to seize control of electronic devices for malicious purposes (think of the implications for cars, planes, or public transportation), or for eavesdropping.
Making firmware more secure will require participation across the supply chain, including chip makers, motherboard makers, and other suppliers, as well as the OEMs. Success will also involve spending more money to make devices secure; that will be the subject of many future discussions. The supply chain implications and engineering required to address the problem will be complex, as well. In the meantime, here are some key points outlining what must be done.
Firming up on-chip firmware
Chip-level code must be engineered better. Open-source firmware should replace proprietary binary code in firmware, for example. Most of the basic code on chips is open-source, and embedded systems run on Linux. However, a lot of the top-layer code, such as the drivers, is not open-source.
Moving up the supply chain, the original device manufacturers (ODMs) that are putting the chips in their devices are adding their own non-open-source code on top of already not-so-great code. The OEMs are often left with unpatchable devices when a vulnerability is reported.
Firmware in embedded systems should thus be completely open-source, and OEMs should be able to fix it easily if a vulnerability is discovered. This, of course, means chip suppliers will have to invest more engineering dollars in fixing their firmware.
Adopting the remote update model
More often than not, embedded system OEMs are forced to recall products when vulnerabilities are exposed. Even if it is possible to install security patches remotely on things like modems, routers, and printers, doing so is usually too difficult for the non-expert. OEMs will thus increasingly need to adopt the PC model for automatic firmware updates, which are downloaded and installed in a transparent way to the end user when the device connects to the Internet.
A preventive shot of software
A potential protective measure is to add layers of software to firmware that can ward off attacks. Researchers at Red Balloon Security, a startup founded by Columbia University computer scientists, reported last summer that code added to firmware can detect and disable malicious code that might otherwise comprise a device.
For example, the researchers said they designed software that protects embedded systems once it is injected into firmware. In many ways, the code functions like traditional anti-malware software designed to detect and neutralize attacks. But the researchers said their software is supposedly unique, because it disables malicious code in a randomized way that is different each time it runs. This means — in theory, at least — that an attacker circumventing the protective code for one device would not be able to attack the same kind of device again in the same way, since the protective code would be different each time.
Look for other firmware anti-virus software in the near future, if it does not exist already. Hopefully, these products will be more effective than PC anti-virus and anti-malware software, which has a poor track record for firmware protection.
Risks assessment in general requires visibility, and that applies to assessing firmware vulnerabilities, as well. You may have a good visibility about firmware from your first-tier supplier, but what about your second-, third-, and even fourth-tier suppliers? It takes a single component with bad firmware to cause problems.
A case in point is when Dell had to report a malware infiltration of its servers. The bad code came from the motherboard, which Dell obviously procured from another supplier. But bad firmware code, as well as counterfeit devices, also could have shown up in devices sold to Dell's motherboard supplier. Dell might have prevented the security lapse and ensuing PR nightmare if it had better assessed this firmware beforehand.
Knowing where and how firmware might be vulnerable at the different stages in the supply chain is crucial. This knowledge and analysis should also be part of a general risk management strategy.