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]

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:how ?

[twitnutttt]

Of course, reading the memory from the computer you booted the hard drive from means you are potentially running a compromised machine if the hard drive is compromised.

But if you booted a different, known-good machine, then mounted the hard drive in question as a secondary drive, it seems feasible you should be able to read and verify the firmware.

Seagate's response here seems ridiculously out of touch, and I can only hope that their posture on this will adapt quickly as the news and newfound scrutiny of the hard drive firmware layer trickle through the organization's practices.

Re:how ?

[Anonymous Coward]

No. The hard drive itself is a computer and is compromised. It doesn't matter if you boot off of it or connect it later. You can't trust anything coming out of the main interface.

Many hard drives have a secondary TTL level serial port that you can use to load new firmware on a bricked drive. It's possible that the serial connection is wired in such a way to be safe from corrupt firmware. So it might be possible to recover a compromised hard drive that way, but I wouldn't trust it without a lot more information about the serial port and how it works than is publicly available.

Re:how ?

[ckatko]

>But if you booted a different, known-good machine, then mounted the hard drive in question as a secondary drive, it seems feasible you should be able to read and verify the firmware.

No... no, you're missing it. The firmware isn't some magical OS. The firmware runs whenever it's connected. Not only when its booted from. Do you know what firmware is?

The firmware handles all requests. So clearly, you are requesting data from something that's tampered with, to see if it's tampered with. It's entirely possible that to make their firmware harder to catch, the firmware would only give you the "false" previous firmware data as you talk to it. Given the complexity of all of their groups viruses we've seen so far, and the fact they compress their payloads, this is not far fetched at all.

I mean, have you ever even used a microcontroller before? How do you think data gets off your hard drive?

Hashes not useful

[IamTheRealMike]

Seagate is correct. Putting a hash on the website doesn't improve security at all because anyone who can change the download can also change the web page containing the hash.

  The fact that this practice is widespread in the Linux world originates from the usage of insecure FTP mirrors run by volunteer admins. There it's possible for a mirror to get hacked independently of the origin web page. A company like Seagate doesn't rely on volunteers at universities to distribute their binaries so the technique is pointless.

A tool to verify the firmware is poetically impossible to write. What code on the drive would provide the firmware in response to a tool query? Oh right ..... the firmware itself. To make it work you need an unflashable boot loader that acts as a root of trust and was designed to do this from the start. But such a thing is basically pointless unless you're trying to detect firmware reflashing malware and that's something that only cropped up as a threat very recently. So I doubt any hard disk has it.

BTW call a spade a spade. Equation Group == NSA TAO

Pretty pointless

[rainer_d]

I guess even if there was a way, the vendor would probably just get a NSL to put the backdoor in himself

I'm still waiting for the first CEO to go to jail for refusing this.
Either it's easy to say "No", or nobody bothers, because "war against terror etc.".

Re:Pretty pointless

[Anonymous Coward]

Obviously the under-reporting of what happened to Joseph Nacchio of Qwest Communications by the corporate media is working.

He refused to cooperate with the NSA because he believed (correctly) that their requests for blanket spying on customers were illegal. Keep in mind this was before Bush signed the law granting telcos retroactive unconstitutional immunity from breaking the law, because every other company apparently cooperated with this. The NSA could have gone to the usually rubber-stampy FISA Court, but apparently they were worried that even that normally useless body would rule against them.

Then Mr. Nacchio got conveniently arrested and charged with "insider trading" and his company got harassed with threats of not getting any more government contracts. He was prevented from bringing up any of the NSA strong arm tactics in his defense because "national security", a concept and government authority I conveniently can't find anywhere in the Constitution of course.

He's out of jail now, fortunately. At the time of course all the national security state types were out trolling that people who believed the NSA would do such things needed tinfoil hats, etc. and now of course thanks to another American hero we know the depths of contempt to which they hold the rule of law and the Constitution.

So one CEO did go to jail for protecting his customers. In fact, with all the dirty dealings, corporate spying, financial misdoings, and basically crashing the US economy in 2008, isn't it funny that the ONLY high profile CEO put in jail of late was somebody trying to do the right thing for average people? Everyone should think long and hard about that.

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: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.

Re:We need hardware write-protect for firmware

[alphatel]

What good will physical switches do if a virus is waiting for you to flip that switch to write-enable so that it can now infect the HDD firmware? Switches would be useful if you never update the firmware. In which case, eliminate the switch and make the firmware permanently read-only. My point is, we need a more secure way to update firmware.

Unless the virus is resident in Bios, (which can also be protected in the same manner), it would be impossible to be infected if you are in a power off state, then enable your switch/jumper, power on, flash your firmware, then disable the switch/jumper after completion before booting into your OS.

In the old floppy days things were pretty much this way. Time to go back.

How it's done: Link to SpritesMods.com article.

[Futurepower(R)]

Jumping to page 3 of the article in SpritesMods.com: Parts on the [hard disk] PCB: "My target was to try and compromise the security of a system by using hard disk firmware mods."

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.