Ask Slashdot: How Does One Verify Hard Drive Firmware?

An anonymous reader writes: In light of recent revelations from Kaspersky Labs about the Equation Group and persistent hard drive malware, I was curious about how easy it might be to verify my own system's drives to see if they were infected. I have no real reason to think they would be, but I was dismayed by the total lack of tools to independently verify such a thing. For instance, Seagate's firmware download pages provide files with no external hash, something Linux distributions do for all of their packages. Neither do they seem to provide a utility to read off the current firmware from a drive and verify its integrity.

Are there any utilities to do such a thing? Why don't these companies provide verification software to users? Has anyone compiled and posted a public list of known-good firmware hashes for the major hard drive vendors and models? This seems to be a critical hole in PC security. I did contact Seagate support asking for hashes of their latest firmware; I got a response stating, "...If you download the firmware directly from our website there is no risk on the file be tampered with." (Their phrasing, not mine.) Methinks somebody hasn't been keeping up with world events lately.

Comments

how ?

[itzly]

This is pointless without JTAG hardware to directly access the flash memory.

Normal users would read/update the firmware through the existing firmware, so if that's been tampered with there's no way you can be sure.

Re:how ?

[storkus]

And how many lay people even know what JTAG is?

You, the individual, can't hope to keep up with organizations that can out-spend you hundreds to thousands of times in terms both man-hours and money. How can you even know if the code you download off the manufacturers' web sites hasn't been tainted during production? Your only hope is to stay below their radar, or have enough trusted people around you or time on your hands to personally go through the code and verify it. I'm betting, even in their mom's basement, hardly anyone has time for that.

Re:how ?

[Anonymous Coward]

Is this some new trend going? This is the second time in a few weeks when someone goes on blabbing about JTAG, again without really knowing what JTAG is.
You don't even know if the controller has a JTAG interface and considering that pretty much all controllers also have alternative means of programming that is faster and require fewer pins than JTAG it is likely that the JTAG pins aren't even available.
Also, the manufacturer would have to be retardedly incompetent if he didn't disable any JTAG or other readout possibility in production since the competitors otherwise could fetch an unencrypted version of the firmware that way.

Re:how ?

[Anonymous Coward]

And how many lay people even know what JTAG is?

This doesn't matter as much as you think. If people who know what JTAG is each verify a few random devices they have access to and find nothing then we know that the majority of devices are okay. The whole general infrastructure is more or less sound. On the other hand if they find a few examples, then there will be proof that there's a problem and there can be a serious attempt to replace everything because there's a real demonstrated problem.

Re:Almost impossible

[itzly]

In the end, such an elaborate scheme is probably directed towards very high value targets. I don't think this is the kind of trojan that runs out in the wild. I could be mistaken, though.

Millions of people doing on-line banking are a high value target. The investment to design a trojan only needs to be done once.

We need hardware write-protect for firmware

[jonwil]

We need jumpers or physical switches that prevent firmware stored in flash (whether it be GPU firmware, BIOS, HDD firmware, network card firmware or whatever) from being overwritten unless you specifically flip that switch.

Secure Boot + Full disk encryption

[vojtech]

Actually, the much hated Secure Boot (with the shim loader, MOK, and GRUB2), combined with full disk encryption (for example using LUKS), and in filesystem compression (btrfs2) can quite nicely protect you from anything that a malicious firmware in a harddrive could do. The firmware will only ever see encrypted data passing through it, except for when loading the bootloader and the kernel, which will both be cryptographically verified by UEFI. The in-filesystem compression is there to compensate for the compression SSD drives normally do themselves to gain additional speed that will be impossible to do that on encrypted data.

Sure, this basically converts the problem to trusting the main BIOS (UEFI), but that's something you have to solve in any case.

Re:How much CPU power & storage in HDD control

[GrangerX]

Well, if you're the drive controller firmware, storage space is a non-consideration for the most part. You can store stuff on the drive platters. A certain percentage of those are reserved for sector reallocation anyway, so you could use those without anyone really every being the wiser.

Re:Pretty pointless

[bill_mcgonigle]

I'm still waiting for the first CEO to go to jail for refusing this.

Dude, you're fourteen years behind the news. The technique is not to get you on the "refusing NSA" charge, but any of the other countless criminal acts you commit every day. This is the primary purpose of a hyper-criminalized environment - so that everybody can be easily bent to the whim of the power structure. See also: charge stacking and the de-facto abolishment of the Sixth Amendment through the plea-bargain process (or, if you're a corporation, the no-plea deal for really efficient fascism.

Re:Seagate HDs

[jeff4747]

With this you can dump what the firmware claims is the buffer and memory of your harddrive.

FTFY.

Re:Hashes not useful

[Anonymous Coward]

SIM cards use symmetric crypto, one copy of the key/shared-secret is kept on the SIM to be sent to subscribers and the other is sent to the PLMN operator and stored (in plain text) in it's Authentication Center. There are many possible ways to steal the shared secrets this way. In some instances those files were sent using plain old FTP, in others they were sent by snail mail and could easily be intercepted en-route by the likes of GCHQ and NSA. It's as low as a fruit may hang on a tree, any lower than this you may as well say it already dropped to the ground.

For a firmware they can use assymetric crypto and the private key can be stored on a HSM, so it can be much harder to steal the key. Sure, they can still probably change the firmware before it is ready for signing if they compromise the vendor's internal network or the firmware developer's computers, and depending if the HSM isn't air-gapped, someone may try using side channel attacks to extract they private keys. Depending on how the firmware is stored, an adversary may simply change the the public key on the drives before it reaches the target, but then it may fail if the user tries to upgrade to a genuine firmware later. Anyway, it's a bit more complicated than stealing shared secrets of SIM cards.

Actually, this is something that has always bothered me. Why are we still relying in old/broken crypto for cell phones? The use of symmetric crypto makes it difficult to make sure the shared secrets never leak and the cyphers used are a joke. A5/1 is a joke and can be broken on a PC. A5/3 has some known flaws too and it's not unconceivable that a high budget adversary may be able to brute force it.