SoylentNews is people
SoylentNews
I ran across this article from last year again and it got me thinking. The article is a story about how a hardware hacker was able to hack hard drive firmware, first to upload his own firmware, but also to take advantage of the embedded controller, and even install linux on the controller. If you haven't read it it's fairly impressive. [Ed's Comment: I would go further and say that it is a amazing piece of hacking, in the traditional meaning of the word.]
It seems that lately there have been a lot of vulnerabilities targeting embedded peripherals. Those in the article come to mind, also badUSB, and some IPMI vulnerabilities.
What do you think? Are the number of attack vectors targeting embedded peripherals a consequence of more powerful controllers? Worse software? More sophisticated attackers? Or just a random occurrence?
(Score: 3, Insightful) by kaszz on Saturday November 29 2014, @03:44PM
Microcontrollers got cheap and manufacturers of motherboards wanted to aid their design. Intel 8048 was used as the keyboard controller early on in IBM-PCs. But the firmware was read-only and cumbersome to program. The new circumstances is re-programmable memory in the form of EEPROM and more powerful MCU in the form of more RAM and faster processing unit. The second stage in this security vulnerability is that these microcontrollers have uncontrolled access to the main computing platform. And their EEPROM allows malware to survive re-installation cleanup.
The cure is to put barriers between the attached microcontrollers and the main computing platform. The second is to lock the firmware either by making it read-only or checking true checksums of all involved microcontrollers at boot and later. The latter won't work for undocumented harddrive controllers which means to stop this a redesign is really needed.
(Score: 1) by OffTheWallSoccer on Sunday November 30 2014, @04:14PM
This is why any embedded system should always have its JTAG port disabled and all firmware-update mechanisms requiring digitally signed firmware images. This particular WD drive did neither. All firmware projects I have worked on in the past ten years have had those two, and some also had encrypted FW images, so that they themselves couldn't be disassembled and reverse engineered.
(Score: 2) by kaszz on Sunday November 30 2014, @09:04PM
I think the JTAG ports should be left working. If physical access is a problem. There's worse to deal with than bad firmware. Better to require signed firmware for upgrade and let the user use the JTAG port to rescue the device or repurpose it. The big problem is that embedded devices have their firmware upgrade option open to the software side of things without any gatekeeper.
(Score: 1) by OffTheWallSoccer on Monday December 01 2014, @07:40AM
I think the JTAG ports should be left working. If physical access is a problem. There's worse to deal with than bad firmware. Better to require signed firmware for upgrade and let the user use the JTAG port to rescue the device or repurpose it.
Disabling JTAG before the device leaves the manufacturing line serves two purposes. First, it closes a big security hole -- letting someone poke around your device's memory will reveal all sorts of things, as shown by the article's author. Second, it prevents competitors from downloading the running (i.e. unencrypted) firmware *from* the device in order to reverse engineer and copy the product (in other words, IP protection).
If you need to provide a mechanism for a device to be unbricked in the field, provide a jumper that forces the device to power up into a simple bootloader that only knows how to receive a signed (preferably also encrypted) firmware image from the host.
As for a user repurposing the device, they really can't do that unless the device internals have been documented by the manufacturer or reverse engineered through security holes. Most device manufacturers aren't in the business of making repurposible (sp?) devices, so they aren't going to make it easy to do so.