Earlier quoted context omitted.
I'd love to read more info about this!
http://www.msfn.org/board/topic/128807-the-solution-for-seag... http://elabz.com/forums/electronics-repairs/list-of-seagate-...
Thanks for the links :)
Hard drive hack provides root access, even after reinstall
21–30 of 96 posts
Re: Hard drive hack provides root access, even after reinstall
#22My knee-jerk reaction was, why didn't WD sign the code and use on-chip fuses and a secure boot path to verify the code before transferring control to anything outside their boot ROM? (Many ARM-based systems-on-a-chip are capable of doing this). Adds cost, for one thing. But you can arrange for the unit to never run a byte of code (even one loaded from the platter) that didn't come from WD.
Good question; how well's that working out on the iPhone?
Re: Hard drive hack provides root access, even after reinstall
#23My knee-jerk reaction was, why didn't WD sign the code and use on-chip fuses and a secure boot path to verify the code before transferring control to anything outside their boot ROM? (Many ARM-based systems-on-a-chip are capable of doing this). Adds cost, for one thing. But you can arrange for the unit to never run a byte of code (even one loaded from the platter) that didn't come from WD.
Your typical motherboard's BIOS code is not signed. Your video card's BIOS is not signed. Your network's card firmware is not signed. Your optical disc drive's firmware is not signed. Etc. This threat vector exists with each of these devices.
As always security is a trade-off. The threat vector of flashing a backdoored BIOS/firmware is irrelevant for 99% of the market: most people will never be targets of such highly-technical attacks.
PS: I tip my hat off to Sprite_TM; fascinating research! I love to disassemble firmware myself :) I liked how you were able to reverse-engineer the data structures in RAM.
Re: Hard drive hack provides root access, even after reinstall
#24My knee-jerk reaction was, why didn't WD sign the code and use on-chip fuses and a secure boot path to verify the code before transferring control to anything outside their boot ROM? (Many ARM-based systems-on-a-chip are capable of doing this). Adds cost, for one thing. But you can arrange for the unit to never run a byte of code (even one loaded from the platter) that didn't come from WD.
The knee jerk reaction to secure boot-anything from the technical community has been generally "No!", "It's a trap" etc.
For PC's and smartphones, which can have higher level security structures, the community is violently against secure boot. For firmware based embedded components, most people aren't so strongly opposed to it.
Re: Hard drive hack provides root access, even after reinstall
#25My knee-jerk reaction was, why didn't WD sign the code and use on-chip fuses and a secure boot path to verify the code before transferring control to anything outside their boot ROM? (Many ARM-based systems-on-a-chip are capable of doing this). Adds cost, for one thing. But you can arrange for the unit to never run a byte of code (even one loaded from the platter) that didn't come from WD.
The knee jerk reaction to secure boot-anything from the technical community has been generally "No!", "It's a trap" etc.
The knee jerk reaction is not to secure boot but to who has the ability to set the keys. The technical community likes to be in control of that.
Re: Hard drive hack provides root access, even after reinstall
#26Earlier quoted context omitted.
I'm not sure about the other controllers, but if this one has a Cortex M3, then anything that runs on an M3 could hypothetically be ported. One of the SE sites assembled a list. Shockingly, the question isn't closed yet! http://electronics.stackexchange.com/questions/27594/what-op...
The Feroceon CPUs are pretty hefty too. They're powering the Marvell Kirkwood platform which is used in things like the Sheevaplug and some of the QNAP TS-* NAS devices. Debian runs great on those. (2.0ghz CPU, 512mb ram). Probably the biggest trouble here is the lack of an MMU (?) .
uclinux can run on mmu-less systems, so I do suspect you can run Linux on this hard drive.
Re: Hard drive hack provides root access, even after reinstall
#27Could this attack compromisse dedicated/rent servers? If so, the attacker could rent, install the exploit on the hardware and terminate the contract.
What about cloud servers? Sure there are virtualization layers, but can't those be breached? If so that would pose imense danger given the distributed nature the hardware exploit could render the entire farm vulnerable
Re: Hard drive hack provides root access, even after reinstall
#28something I hadn't really considered about hard disk encryption, before reading this, is how it could protect against compromised disk controllers. if the OS encrypts the data stored on the disk, it would be a lot harder (perhaps, with the right composition, impossible) for a malicious disk controller to insert/change/modify important data (like code, or password files) stored on the computer.
we think of the system as a holistic entity, but turned on its head, you can see how the inside of a computer is just a network...
Re: Hard drive hack provides root access, even after reinstall
#29what is that cortex-M3 chip doing? Did the NSA put it there?
Re: Hard drive hack provides root access, even after reinstall
#30My knee-jerk reaction was, why didn't WD sign the code and use on-chip fuses and a secure boot path to verify the code before transferring control to anything outside their boot ROM? (Many ARM-based systems-on-a-chip are capable of doing this). Adds cost, for one thing. But you can arrange for the unit to never run a byte of code (even one loaded from the platter) that didn't come from WD.
Your typical motherboard's BIOS code is not signed. Your video card's BIOS is not signed. Your network's card firmware is not signed. Your optical disc drive's firmware is not signed. Etc. This threat vector exists with each of these devices. As always security is a trade-off. The threat vector of flashing a backdoored BIOS/firmware is irrelevant for 99% of the market: most people will never be targets of such highly…
In Secure Boot environments, this is all untrue - all option ROMs are signed, and the firmware should only accept signed updates. That pushes the problem out to ancillary devices that we've traditionally thought of as safe, but this demonstrates that they really need to reconsider.