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

[earthminion]

@AC, "some new trend" and "someone goes on blabbing about JTAG" ... No its not a new trend, people like you who don't really know about JTAG, have always trolled down comments they don't like (oh the irony). The fact is JTAG is about as near to a standard as we have with embedded CPUs and all developers of embedded systems know about and use JTAG. Also how do you think the initial bootloader firmware gets on the embedded systems during manufacturing? ... I'll give you a clue, JTAG.

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 ?

[fisted]

Ehm, first of all, JTAG isn't only used for downloading firmware to your device, it's also a debugging interface and *very* widespread.
Second, you don't typically "disable" the JTAG interface on a released device -- what you do is set some "lock bits" or equivalent in the MCU, so the firmware cannot be read. No need to disable JTAG for that.

But sure, go on demonstrating how little you know about the matter... AC after all.

Re:how ?

[fisted]

Right, manufacturers typically spend a shitload of $ to engineer their own debug interface and the respective hardware for it when there's an established and well-designed open standard around.

Re:how ?

[wvmarle]

How can you even know if the code you download off the manufacturers' web sites hasn't been tainted during production?

You can't, but you can be quite sure that the manufacturer will take serious measures to make sure this doesn't happen. This protection against tampering to compromise computers just piggybacks on more general protections to keep firmware sound, such as tests to make sure there are no bugs in the firmware that cause data loss, and that software published on the web site is the software the company intends to publish.

This for the simple reason that one mistake here may result in bankruptcy, as people may lose trust in the whole company. Without trust in its products by its customers, a company can't survive - especially when it's about storing valuable data.

Re:how ?

[X0563511]

Sure, if there's a competitive reason to do so.

After all, they do the same for power/data/audio connectors too. (or at least they did.. *cough*nokia*cough* )

Re:how ?

[Greyfox]

Feel free to put a feature request in with the NSA to please make their viruses easier to spot in the future.

Re:how ?

[currently_awake]

If the NSA can sneak in and swipe the SIM card keys then sneaking into the factory and "updating" hard drive firmware won't pose any difficulty at all. If they alter the firmware for all hard drives to add a backdoor, that would be sufficient for their needs. As a bonus they could alter a common drive controller chip to be sensitive to RF, allowing remote exploit.

Re:how ?

[wvmarle]

Copying some data is quite different from replacing data, and far easier to do unnoticed. The NSA copied existing SIM encryption keys; they did not attempt to replace them with their own keys or so.

It is pretty hard to detect an intrusion, access to data, and copying of that data. Especially if the attacker gets access through an authorised account by getting their hands on someone's login credentials.

It is much easier to detect the replacement of data: this can be done with e.g. automated cryptographic checksum tests against remotely stored known good checksums, or against a freshly compiled copy.

A lot of data will have to be replaced unnoticed (source code is being read by humans, who may detect changes if it happens to be the part they work with) to stand any chance of getting a compromised binary on someone else's site unnoticed.

Re:how ?

[eth1]

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.

This. We have reached the point where electronic security for most individuals is simply not possible. The problem is that it's "hard," and most people that aren't security professionals (and even some that are) will never understand how things like encryption, asymmetric keys, etc. work. Which means that in order to secure themselves, they HAVE TO trust someone to take care of those details for them. But any company these days essentially has to be assumed to be under the control of a government, or will instantly fold when pressed.

And even if you're comfortable managing keys and such, you probably can't write your own software (especially strong encryption algorithms) and build your own hardware.

Re:how ?

[bill_mcgonigle]

I'm betting, even in their mom's basement, hardly anyone has time for that.

Time and money are fungible in this case (buy equipment, hire an expert). Rich corporations have time and money to do this. "The People" most certainly do not. Plutocracy managed.

Re:how ?

[kenshin33]

how a bout a simple MitM, forcing someone to download what they think is the legitimate firmware when they are not (not that publishing any hash on said would counter that ).

Re:how ?

[ShanghaiBill]

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, you would be going through the processor on the HDD, that is running the supposedly compromised firmware. There would be nothing to stop it from lying to you about updating itself. Firmware malware would most likely be implemented as a stub that checks for a special key like "NSA_1234", and otherwise jumps to the "real" firmware, so there would be no way to test for its presence without knowing the key. They only way to be sure, would be to write directly to the flash via the JTAG port.

Moving the HDD to a different computer would make no difference, since the firmware is in the drive.

Re:how ?

[AK Marc]

You can't, but you can be quite sure that the manufacturer will take serious measures to make sure this doesn't happen.

I worked for HP when every computer re-imaged in their repair shop was sent out with a virus. Other makers have essentially recalled new PCs for the same thing. I can't give cites, because it's covered up. 10x the budget of the repair department was spent to hide the problem. To convince people it can't happen. Must trust the chain of trust. Even when it's broken.

Re:how ?

[ArmoredDragon]

Off hand I can already think of a technique I myself have deployed (not written by me) when hacking DirecTV smart cards, or what I know Xbox 360 mod chip users do: Use "stealthing" code that presents the data that is SUPPOSED to be there when asked by any existing commands that are used to read the firmware contents, but otherwise the hacked code is what gets executed during normal running operation.

It wouldn't surprise me if whoever wrote this went to such lengths to add this kind of feature to their firmware. I mean look how excruciatingly feature packed stuxnet was.

Re:how ?

[ArmoredDragon]

Sure, if there's a competitive reason to do so.

There isn't one. If somebody REALLY wanted to rip off the firmware, they'd just unsolder the chip and buy a matching reader for about $50 from digikey. The skills required to do it aren't terribly difficult, and in fact it requires less skill to pull that off than it does to read from a jtag port.

Any EE worth a shit would be well aware of that, and wouldn't bother disabling the jtag for that reason; if anything they'd prefer to leave it intact to facilitate troubleshooting RMA'ed parts so that they are cheaper to refurbish.

Re:how ?

[BLKMGK]

Much of the code isn't stored on a chip that can be unsoldered but what you've said is correct so far as simply pulling code off of chips.

Re:how ?

[fisted]

Was there a viable standard for this at that time?

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?

Re:how ?

[earthminion]

"JTAG isn't only used for downloading firmware to your device"

I never said it was. You are playing a straw man argument, misrepresenting me then attacking that misrepresentation.

Re:how ?

[Jane Q. Public]

It would be pretty darned simple for the HD manufacturers to provide a utility for checking the firmware against stock versions. In most cases a simple MD5 hash would probably do.

While MD5 is not the absolute most secure thing around, it is very difficult to make custom software fit an existing hash.

Re:how ?

[Microlith]

Many hard drives have a secondary TTL level serial port that you can use to load new firmware on a bricked drive.

That depends on how the vendor utilized the serial port and how they do their boot sequence. If it's anything above baseline chip support, you might not be able to do anything useful with it.

Re:how ?

[fisted]

I never said you said that, but you mentioned it only in the context of programming.
Besides, you ignore the entire rest of the response.. Pot, meet kettle.

Re:how ?

[wvmarle]

As many already pointed out: you can not trust the firmware image provided by the drive itself, for the simple reason that you have to talk to the very firmware you try to verify, and which may be compromised.

Think of the kid calling "are there any monsters under the bed?", and the monster under the bed answering "no!".

Re:how ?

[AK Marc]

Was it called McAfee?

But seriously, nearly every maker has had it happen. Sometimes with new computers. For the case I have personal knowledge about, it was from the repair center.

Re:how ?

[Jane Q. Public]

As many already pointed out: you can not trust the firmware image provided by the drive itself, for the simple reason that you have to talk to the very firmware you try to verify, and which may be compromised.

I don't buy it. The fact that you can upgrade firmware implies that the hardware exists for you to read as well as write the raw contents, without having to interact with those contents. It's a simple matter of reading sequential memory locations.

Writing firmware that upgrades other firmware would be an exercise in silliness. First: its function is fixed and should never need to be changed (if the design wasn't blatantly half-assed to begin with), and second, a PLA or other other write-once chip is simpler and cheaper than a general-purpose processor.

Re:how ?

[OffTheWallSoccer]

Very often the JTAG port is simply left open.

Most any project engineered by smart people will indeed have disabled JTAG for production units. To not do so is to invite security, IP and possibly liability issues.

The CPU is typically connected to external flash anyway. Worst case you have to unsolder the flash and read it that way.

Many microcontrollers have onboard flash, whose contents can be configured to not be readable by external means (i.e., address/data pins). For microcontrollers that have firmware stored in an external flash, any company that values their IP will encrypt their FW before writing it to flash and decrypt it during boot up.

Re:how ?

[postbigbang]

If you had a valid, uncompromised version of firmware, and were able to substitute it, and look at the streams, you could compare one stream to the other, uncompromised vs suspect. At some point, to do its work, the suspect firmware has to cough something different, be it an altered MBR, or something else to allow it to do its job. Otherwise, its sits in firmware forever doing nothing. There needs to be a routine, an exercise, comparing known vs unknown to assess what it does to a stream, or to infect/root its host.

I get the feeling that the NSA attack is likely focused on a fairly select few, otherwise the C&C traffic would be heavy enough to otherwise detect. A rooted machine may stay asleep for a long time, perhaps forever, but at some point, it has to wake up. Change your IP address to a CIDR block in Iraq and see if your router suddenly lights up.

Summary: to do its work, it has to either talk to something or infect/root the kernel or something the kernel uses a lot, otherwise, it's useless except as a local attack. It has to assert itself, and using known vs unknown analysis is perhaps the only real way of making it show its footprints in the snow.

Re:how ?

[OffTheWallSoccer]

If somebody REALLY wanted to rip off the firmware, they'd just unsolder the chip and buy a matching reader for about $50 from digikey.

I just posted this a few comments up, but applies here, as well:
For microcontrollers that have firmware stored in an external flash, any company that values their IP will encrypt their FW before writing it to flash and decrypt it during boot up.

Re:how ?

[AmiMoJo]

JTAG might not be enough, if they have disabled it after programming to protect the firmware. It's even possible that the JTAG interface was interfered with somehow and returns false data. Firmware can still be checked but only by more destructive means, e.g. decapping the chip.

The question is what to do in the mean time. Personally I buy all my storage media in cash, in person in the far east. I only buy Japanese/Chinese/Korean drives that are made in the far east and never pass through the US, UK or other FIVEEYS countries. Of course, they might be bugged by one of those countries, but I'm not nearly as worried about China spying on me as I am about GCHQ or the NSA spying on me.

Re:how ?

[AmiMoJo]

Actually it is pretty common to disable JTAG on consumer hardware. Sometimes it can be done in software and so the possibly of re-enabling it in a sort of debug mode exists. Typically though it's just disabled because it isn't needed. Hard drive manufacturers ship millions of units, and when they come back for repair they aren't interested in doing a careful diagnostic with JTAG. The controller tells them what is wrong, or if it is dead they just replace it and start the self diagnostic before sending the drive back out as a refurb.

Another reason to disable JTAG is security. These days many drives support encryption, especially SSDs, or at least some kind of password (ATA password feature). It used to be easy to circumvent because passwords and keys were stored in the controller's RAM or sniffable off the data bus, but manufacturers got wise to that. Disabling JTAG stops the RAM being read back easily.

Re:how ?

[rs79]

I used to write hard drive firmware.

Here's what I would do: pull the controller board off a drive. Write a piece of software that emulates the physical drive to take it out of the equation.

You have to find a way to read the firmware. If you have to desolder a chop ad read it that's ok. Do this to many drives and eventually you'l find one of these that isn't like the other.

Now figure out what it's doing.
The firmware on those drives is not in the slightest bit complicated it's actually very straightforward.

Old SCSI drives circa late 80s is where I'd start looking.

Re:how ?

[rs79]

This is why we have logic analyzers.

Re:how ?

[Cramer]

Even with JTAG (hint: most drives don't have a JTAG header), all you'd get is the tiny bootloader. Almost everyone stores the full firmware on the plater. (because a 32K flash is cheaper than 8M)

(NOTE: This is a **MAJOR** cause of drive failure. The protected sections where the firmware is stored is never "refreshed"; when it becomes too weak to read, the drive is a paperweight.)

Re:how ?

[lightbounce]

It depends. Some manufacturers have a simple bootloader hardcoded into their SOC.

Re:how ?

[lightbounce]

You can't, but you can be quite sure that the manufacturer will take serious measures to make sure this doesn't happen.

You'd think, but it turns out that isn't so. Have a look at https://spritesmods.com/?art=h... where Jeroen Domburg hacked into a WD 2TB Green drive using the JTAG port. He was able to modify the firmware and store it in the external flash chip holding the firmware.

Drive manufacturers still seem to be relying on "security by obscurity"

Re:how ?

[wvmarle]

Please read the thread before you reply.

This was about firmware images provided on the web site of the manufacturer. Not about reading/modifying the firmware of a drive - which indeed we know is possible by design (otherwise this whole discussion would be pointless to begin with).

Re:how ?

[OffTheWallSoccer]

How is a logic analyzer going to help? During bootup, the microcontroller is going to read encrypted firmware code from the flash, so snooping that will be useless. The decryption process itself will take place in the RAM internal to the microcontroller, which isn't exposed on any external pins, so no snooping.

Almost impossible

[ponos]

Firmware is usually not signed. Furthermore, I am not even sure that most drives support reading the firmware. Overwriting with a "fresh" firmware might also be impossible, since I assume it happens through vendor extensions of said firmware. A malicious version could be able to thus protect itself.

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.

Like you, I do wish it becomes more secure in the future. If anyone has a list of vulnerable targets (brands, models etc), I would be interested to know.

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.

Re:Almost impossible

[Anonymous Coward]

Millions of people doing on-line banking are a high value target.

Not really. This is professional spyware tailored for government and industrial espionage, and likely to have very selected targets.

Re:Almost impossible

[thegarbz]

Yes we could concoct an elaborate scheme involving some deep firmware hacks on people's harddrive which is highly hardware dependent.

Or you could just send the people a phishing email.

I know which I would be doing if I were going after the millions of dumb users out there.

Re:Almost impossible

[ponos]

Ebanking often depends on two-factor authentication. Furthermore, this is exactly the kind of situation that would rapidly generate enormous publicity. Do you think that people losing thousands or millions are not going to notice? A firmware trojan in that situation would be very short-lived. Everything is possible, of course, but I would be more inclined to think industrial espionage or three-letter agencies, where this kind of "weapon" is likely to be used with discretion and over a long time.

Re:Almost impossible

[dpidcoe]

It doesn't matter who made the exploit or who their targets are. Once the exploit is out there, it's there for anyone to take control of. The NSA may very well only be interested in a few high value machines, and could even be the most trustworthy people on the planet (lol), but there's no reason someone else couldn't stumble across the NSAs backdoor (I'm sure that just like how we saw stuxnet infect thousands of non-target machines, it won't be limited to just the handful of targeted computers) and start using it for their own ends.

It's one of the reasons it's so annoying when people pull the "well what use is my data to [entity collecting it]? It's not like they're going to do anything nefarious with it". The problem isn't the trustworthiness of the people collecting it, the problem is that now you've effectively doubled the risk of that data being stolen by a random hacker

Tin Foil

[Anonymous Coward]

Best solution is to wrap your hard drive in tin foil to keep the harmful mind-rays out.

Not considered a real risk - at least, until now.

[wvmarle]

Most likely there are no such tools as no-one thought it could be a vector of infection. Just like the BIOS; which used to be a non-reprogrammable ROM chip. I for one didn't know current hard drives even had firmware that can be replaced by the user, let alone that it may be a potential attack vector for malware.

Depending on how hard it is to read the installed firmware from a hard drive (is this even possible in the first place?) it shouldn't be too hard to write a tool that can read the firmware, and calculate a checksum for verification. The hard part is going to be, how do you know that your software gets the actually installed firmware - or just a known good but inactive piece of code provided by a compromised firmware, pretending that this is the software that's installed? The moment a firmware is installed, you probably need to call onto that very firmware to get a copy of it from the drive. Unless this read-firmware routine is provided by a special, hard coded circuit.

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

Re:Hashes not useful

[invictusvoyd]

MAybe HDD manufacturers should ship a hash in print along with their drives which can be then tallied with the one on the website .. they cant hack every hard disk shrinkwrap can they ?

Re:Hashes not useful

[itzly]

What they need to do is put a bootloader in there that can't be read or modified, and then sign the firmware binary with the bootloader's key.

Re:Hashes not useful

[fph il quozientatore]

MAybe HDD manufacturers should ship a hash in print along with their drives which can be then tallied with the one on the website .. they cant hack every hard disk shrinkwrap can they ?

At this point, they could simply ship their public key in print and sign all present and future versions.

Re: Hashes not useful

[Anonymous Coward]

Even if a hacked firmware isn't calling home, there are many things it can do. A simple example is detecting a read of /etc/shadow and replacing the hash for the root password with a known hash. Pwned.

Re: Hashes not useful

[Eunuchswear]

Another reason to use an encrypted root.

Of course there are ways to get round that, too, but the size of the hard drive firrnware is limited.

Re:Hashes not useful

[infolation]

Until someone does a Gemalto, and swipes their private key database.

Re:Hashes not useful

[amck]

Won't work. See the modification of Cisco hardware intercepted between manufacture and delivery.

Open-source the whole stack. Require access to reflash the firmware securely by independent means.

Previously I would have thought this a pipedream, but with China looking to deny access to its markets to insecure equipment, I'm hopeful that this will happen.

Re:Hashes not useful

[Anonymous Coward]

The old BIOS jumper trick might just work. Since the user doesn't update the flash frequently anyway, an integrated mechanical lock switch might do the job.

Re:Hashes not useful

[BitZtream]

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.

Which is why I always laugh my ass off at all these people who use PGP to sign things and put a hash on the same website you download it from ... look you can verify this file you downloaded from the website hasn't changed because theres no way anyone would be smart enough to update the hash as well!

And that my friends is why PGP is effectively useless in the real world unless you physically exchange keys securely.

Re: Hashes not useful

[Anonymous Coward]

Another reason to use an encrypted root.

Of course there are ways to get round that, too, but the size of the hard drive firrnware is limited.

The capacity of the firmware chip itself might be limited, but they can always map off portions of the platters to store such code. There are already inaccessible portions that are used for redundancy/overprovisioning/remapping of bad sectors.

Re:Hashes not useful

[hey!]

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.

While I agree just slapping a hashtag on a webpage doesn't necessarily improve security, it doesn't follow that it can't.

Security is a holistic property; it's a property of a system as a whole. An important part of that is detecting when you've been hacked and knowing in advance what you're going to do. There are many scenarios under which publishing the hash codes of downloads improves security, but that *always* depends on people doing certain things, many of which can be automated on the vendor end.

Re:Hashes not useful

[Splab]

If something in your computer is compromised, you are f*cked. At defcon they demonstrated the ability to infect multiple hardware devices on the PCI bus, so even if you manage to get rid of the malware from one device, it was still spreading from the rest.

Re:Hashes not useful

[bill_mcgonigle]

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. ... A company like Seagate doesn't rely on volunteers at universities to distribute their binaries so the technique is pointless.

There are many possible attacks. A hash on a website is not invulnerable to a rogue employee at Seagate (or one "just following orders").

A hash protects against a rouge insertion at the endpoint. Like if your PC is compromised by an attacker and then you pull the hard drive and [assuming there's a way to get a hash from SMART/ATAPI) you can compare the hash of the firmware that the drive is running to the list of published firmwares at the vendor's site. If the attackers are only modifying a small subset of drives, this works fine - they can't also intercept the check to the vendor's site - not unless they've broken TLS and/or have malware on every possible machine.

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.

Well, today you can pull the image from JTAG, or so the experts have said (you can verify the firmware directly from memory with a hash if you have moderate funding). There's all sorts of talk about how ATAPI is write-only for firmware because the vendors don't want their competition to get their code and decompile it. This appears to be nonsense, as any other drive vendor already has the debug tools to pull such things from memory, and extracting it from an update isn't that hard - if a 16K DOS update utility can extract it, so can a multi-billion dollar R&D company.

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.

They most certainly do not. So, here we are at today and need a way forward. There are a few ways forward, a fistful of crypto protocols to choose from to ensure future usefulness of hard drives for security applications, and INCITS/SATA-IO ought to be having emergency meetings _right now_ because this (NSA/GCHQ) is a major threat to the industry. The vendors may need to move operations outside of five-eyes to remain commercially viable.

Re:Hashes not useful

[jeff4747]

Why does the firmware on the drive have to report it's actual hash? The malware could easily respond with a "known good" hash.

You reading the firmware and calculating your own hash? Why does the malware have to respond with the firmware that is actually running? Again, respond with a "known good" firmware image, and go on your merry way.

Re:Hashes not useful

[jeff4747]

Open-source the whole stack

Won't work. No one is actually looking for esoteric bugs in complex code that can lead to an attack. See: glibc.

Require access to reflash the firmware securely by independent means.

The firmware image on the device does not have to let you reflash it. It can happily report "success!" while doing nothing. It can also re-infect the new image - the device is powered, so the existing firmware can be running. Additionally, you're assuming this "independent reflasher" is itself secure.

Previously I would have thought this a pipedream

Yes, this is entirely a new phenomenon.

Re:Hashes not useful

[jeff4747]

Like if your PC is compromised by an attacker and then you pull the hard drive and [assuming there's a way to get a hash from SMART/ATAPI) you can compare the hash of the firmware that the drive is running to the list of published firmwares at the vendor's site.

Why does the malware have to respond with the actual hash of the firmware? Respond with one of the "known good" hashes.

If you're reading the firmware and calculating a hash, the firmware does not have to give you the firmware that is actually running. Respond with a "known good" firmware image.

Depending on the design of the firmware and the controller chips, even JTAG may not help you - they don't have to actually give you raw access to the device's memory. They're supposed to, but we're not talking about the laws of physics here. The "rules" can be violated.

The vendors may need to move operations outside of five-eyes to remain commercially viable.

Yeah, only five-eyes nations do this kind of thing.

Re:Hashes not useful

[Immerman]

As others have pointed out - so long as you're downloading your firmware from their website instead of a third party, anyone who compromised the firmware could compromise the hash just as easily. It's become a common thing in the OSS community because volunteer mirrors are common, any of which might be compromised.

The only exception I can think of is internet malware that modifies your download while in transit, though if it can appropriately identify and modify your firmware download, it can probably also modify the web page listing the hash.

Re:Hashes not useful

[hey!]

Again not necessarily. For example the web page and the download server might not be the same, in which case it is not true that being able to modify the download necessarily means you can also modify the webpage checksum.

Another example is when people download and stage a large file on their local network, which is very common practice. If the server on their local network, in a sense the file is modified "in transit", but the malware needn't be anything special or exotic. I'd go so far as to say if you stage anything on your own servers you ought to check its hash religiously before using it.

Yet another example of "not necessarily" is monitoring. It wouldn't be hard to automatically monitor the download page for unauthorized modifications. Of course you should monitor the downloads themselves for modifications, but that takes more time. You can monitor the hashes on the download page continuously from another computer, automatically shutting the page down if anything changes. That wouldn't prevent your download page from unauthorized modifications but it would contain the consequences and it's very easy to do.

This is what I mean by it's the stuff that goes *around* a security measure that makes it work. A hash doesn't do anything unless people check the hash. That includes people who are hosting the file. I often think of this as a kind of diminishing returns exercise; since people often have spent *no* effort on preparing to respond to being hacked, often the best marginal expenditure is in that direction.

Re:Hashes not useful

[grcumb]

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.

Perhaps, but the change would be kind of visible. It would be trivially easy to require concurrent events to be associated with the key change, e.g. have an SVP send an email stating, 'I confirm the new hash key is $FOO' to half a dozen senior technical employees. The odds of all of them being compromised is vanishingly small.

A tool to verify the firmware is poetically impossible to write.

Writing phonetically for meter:

foreach dollar testkey in foo{
while input is not empty { do {
test result equals (hash lookup in sequel)
}}
if (test result's good) return true;

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.

Re:Hashes not useful

[janoc]

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.

Sorry, but that isn't how it works. The role of the MD5/SHA1 hash on the website is not security but the ability to quickly check whether or not the download was corrupted in transfer so that you don't waste time burning a corrupted ISO image, for example.

The real security feature are the cryptographic signatures inside the packages themselves. Both RPM and DEB formats allow the use of these and most Linux distros use them. There is both a hash and a crypto signature to check that the package comes from who it claims to be coming from and that it wasn't tampered with.

Re:Hashes not useful

[sectokia]

If the circuit was open source such that you could read the memory directly with out using any untrusted software, then the is no reason why a published hash won't work. Have the firmware is a known i2c chip that anyone can read from.

Re:Hashes not useful

[invictusvoyd]

were'nt number station supposed to broadcast numbers ? did they do morse as well? I have tuned into a couple of them when I was in school , tinkering with my SW reciever. Spooky voices ..

Re:Hashes not useful

[cupnoodleboy]

The vendors may need to move operations outside of five-eyes to remain commercially viable.

Do you really believe that only the "five-eyes" countries are capable of doing this? Countries like Russia certainly have the technology and money to do something similar. Countries like Somalia would not be capable of doing this, but then you would have great difficulties in actually building a factory, or developing any technology there.

Re:Hashes not useful

[AmiMoJo]

It can be done with cryptographic signing with a private key, and verification with a public key. That's how Tails distribute their CD images over insecure means such as Bittorrent and HTTP. No-one can modify the binary and sign it without access to Tail's private key.

Re:Hashes not useful

[lightbounce]

This appears to be nonsense, as any other drive vendor already has the debug tools to pull such things from memory, and extracting it from an update isn't that hard.

That's true of course. But the level of expertise at major drive vendors like WD and Seagate is so high that there's no need to steal the code from a competitor. If it comes down to it for a critical piece of technology, you just steal the employee instead. It's cheaper and more legal. On top of that, employees move back and forth on their own so over time knowledge is shared.

Besides, the hardware designs and technology of the manufacturers are different enough that the code can't be shared directly. You'd have to spend lots of money reverse-engineering it and then adapting it to your hardware. For the engineers at these companies -- who are the world-class experts at drive engineering -- it's quicker and cheaper just to design and write your own.

Re:Hashes not useful

[jeff4747]

That's how it should be done, but that isn't necessarily how it always will be done. An executive hears that a simple device would let just anyone read their valuable firmware, and suddenly he wants to disable the interface unless you execute a super-secret command. And now your JTAG interface isn't raw hardware access.

Re:Hashes not useful

[Agripa]

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.

More importantly Seagate has nothing to gain and much to lose if they provide a means to verify that their hardware has not be altered. Right now there is no way to know so Seagate can just deny it. Providing a means to prove it can only make them look bad and add to their already numerous customer service problems.

In light of the above, I assume that *all* Seagate products have been compromised by the NSA from the factory.

Re:Hashes not useful

[Agripa]

There are many possible attacks. A hash on a website is not invulnerable to a rogue employee at Seagate (or one "just following orders").

Even worse from Seagate's perspective, when the hash and website *are* compromised it just makes them look worse.

Re:Hashes not useful

[Agripa]

Being able to read the Flash image back over JTAG for comparison would be a good start.

Better I think would be to add hardware write protection which for Flash used to be fail-safe since it relied on an external programming supply but those days are long gone. Now you would have to tie the write protection into the write strobe which assumed access to it.

Re:Hashes not useful

[amck]

>> Require access to reflash the firmware securely by independent means.
> The firmware image on the device does not have to let you reflash it. It can happily report "success!" while doing nothing

Agreed: if the firmware is malware then it cannot be trusted, period. By "require access" I mean something like JTAG bus that enables you to replace the firmware reliably, given that you assume malicious firmware to start with.
This requires someone demanding such hardware features, which is why I doubted it would happen. Given China's recent actions, I'm now inclined to think it will happen - Intel, Cisco, etc. are not going to give up the Chinese market if the Chinese demand such features.

Re:bennett haselton -- what remains what he can't

[jcr]

Kid, take your meds and fuck off.

-jcr

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

[swillden]

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

NSLs can't do that. The law is quite specific about what an NSL can request. Not only can't it demand pro-active measures like backdoors, NSLs can't even demand the content of communications that the recipient already has. NSLs are limited by law to demanding communications metadata only.

Well, I suppose a letter can be issued that demands anything at all, and companies may choose to comply, but they don't legally have to if the letter specifies more than what is allowed by law.

Re:Pretty pointless

[currently_awake]

You are assuming the company would know the legal limits of an NSL. you are assuming the company would care about legal limits. If the NSA agent makes a good case of "Terrorism" then they will likely get what they want.

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:Pretty pointless

[swillden]

You are assuming the company would know the legal limits of an NSL. you are assuming the company would care about legal limits. If the NSA agent makes a good case of "Terrorism" then they will likely get what they want.

Of course the company would know the legal limits. They have attorneys.

That they might not care I addressed in the second paragraph.

Re:Pretty pointless

[rainer_d]

I know about Quest.
But as you say, that was fourteen years ago.
And it was (IMO) partly his fault.
Apple's accounting has been under the microscope for a couple of years, going as far as citing the CEO in front of a Senate hearing. Given the state of Uncle Sam's finances, I guess they would have found something by now.

Re:Pretty pointless

[Immerman]

The problem, unfortunately, is that to get such trials you must first overthrow the power-structure issuing the orders. Now, that might happen if we could get enough people of their ass to vote out the fascists controlling this country - but thus far I haven't seen any real viable opposition, mostly just a bunch of disorganized wingnuts. So what are you going to do - follow orders and risk facing persecution if your overlords are overthrown, or refuse to comply and definitely face persecution now?

Re:Pretty pointless

[Agripa]

NSLs can't do that. The law is quite specific about what an NSL can request. Not only can't it demand pro-active measures like backdoors, NSLs can't even demand the content of communications that the recipient already has. NSLs are limited by law to demanding communications metadata only.

I assume the communication companies were handing over a lot more than the NSLs can demand in the spirit of cooperation and that is why the retroactive immunity was necessary. The safe bet is that everything including content is handed over where it can be used for parallel construction to avoid court review.

Re:Pretty pointless

[swillden]

I assume the communication companies were handing over a lot more than the NSLs can demand in the spirit of cooperation and that is why the retroactive immunity was necessary

The GP wasn't suggesting that excessive data was handed over, he said that an NSL could be used to demand installation of a backdoor. If I were a vendor, even one who really wanted to be cooperative, I'd balk at that, because the chances of something like a backdoor being discovered are too high. It would be actively sabotaging my customers, and not just to the NSA... a backdoor can't distinguish between users, it lets in anyone who figures it out. And, of course, if the existence of the backdoor were published it would do serious damage to my business.

Even companies who want to cooperate are going to be reluctant to do potentially business-destroying favors for the government. There would be a great deal of incentive to fall back on the law and refuse on the grounds that the law doesn't authorize such requests.

Re:Pretty pointless

[Agripa]

If I were a vendor, even one who really wanted to be cooperative, I'd balk at that, because the chances of something like a backdoor being discovered are too high. It would be actively sabotaging my customers, and not just to the NSA.

That did not stop RSA from including NSA's compromised random number generator and making it the default selection. Maybe their alternatives included a secret court order, NSL, or being paid 10 million dollars.

I agree that it would be one hell of a risk.

Re:Pretty pointless

[swillden]

If I were a vendor, even one who really wanted to be cooperative, I'd balk at that, because the chances of something like a backdoor being discovered are too high. It would be actively sabotaging my customers, and not just to the NSA.

That did not stop RSA from including NSA's compromised random number generator and making it the default selection. Maybe their alternatives included a secret court order, NSL, or being paid 10 million dollars.

Indeed it didn't. Idiots. $10M appeared to do the trick. Though they did apparently take the money and adopt the PRNG before it was realized that it was likely backdoored, and before we realized that the NSA had abandoned their mission to improve US COMSEC.

power signature?

[Anonymous Coward]

If you ask the drive to read out the whole flash.
The maybe the firmware would have to go to the platter to get the real image.
This might have a different power consumption or sound than a real drive going to the flash?

Might not work for a solid state drive.

JTAG seems safer.

Re:bennett Haselton

[Anonymous Coward]

WTF? No stories by him have been posted here in weeks. Find a new anti-meme or GTFO.

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

[drinkypoo]

Amen. A firmware write-protect jumper is the only rational solution. Ideally it goes on the front of the drive so it can reasonably be diddled without pulling drives out of arrays.

Re:We need hardware write-protect for firmware

[Anonymous Coward]

In the back of my head for several years now I was thinking the same about the operating system.

Total ignorance of the nut and bolts of OS interiors, but put a copy of the OS on a physically protected chip to verify the integrity of the OS. Yes some files do change but they can be handled as exceptions and stored else wise.

Re:We need hardware write-protect for firmware

[gnupun]

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.

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.

Re:We need hardware write-protect for firmware

[gnupun]

This could work. As long as the OS is not started during the update... only an uninfected BIOS running and a flash drive would be involved in updating whatever firmware requires updating.

Also, the BIOS should flag an error and stop booting to OS if any firmware switch is in the write-enable position.

Re:We need hardware write-protect for firmware

[MrKevvy]

Absurd... just how often do we ever need to update our drive firmware? I've never had to in twenty years and as many computers. And given this revelation I never would want to turn off the write-protect for a likely unnecessary update.

Re:We need hardware write-protect for firmware

[baka_toroi]

SSD's firmware get many necessary updates.

Re:We need hardware write-protect for firmware

[thegarbz]

The interesting part about waiting to flip the switch is the "why" part. Why would you flip the switch? To install new firmware of course. Why flash firmware on the HDD? Because you have a problem with the current one.

This results in a few scenarios:

1. The malware is hyper advanced and automatically updates to infect the latest firmware.
2. The malware fails as soon as the user updates the latest firmware.
3. The malware completely overwrites the new firmware with the result that the user may attempt to re-flash or even send the drive back because the problem isn't fixed by the firmware that isn't currently installed because of the malware.

For this attack to work we're looking at malware of rather insane sophistication in which case I highly doubt I'm the target.

Re:We need hardware write-protect for firmware

[hey!]

That's a bit like saying that having a portcullis in the castle gate doesn't help you if the enemy is already inside the walls, which is unquestionably true, but misses the point that having the portcullis makes it harder (although not impossible) for the enemy to do that.

I agree that a more secure way to update firmware, but we have to be realistic in that this would also tend to create new targets for malware writers (e.g. stealing signing keys).

I suspect what we really need is stuff that will occur *outside the box*, such as better vendor of firmware downloads and some kind of police agency tasked with discovering and investigating dodgy firmware. But of course the objection remains -- such an agency itself would be a potential source of problems.

Re:We need hardware write-protect for firmware

[davecb]

We always had that on old Suns, as you could easily brick entire systems by running a bad update. When disks started showing up with downloaded firmware, we were surprised that viruses *didn't* start bricking them with cat /dev/nul | xg_config --some-options

Re:We need hardware write-protect for firmware

[kimvette]

If you've got HP blade servers and call in with something even as mundane as a hard drive or mezzanine card failure, they will often insist you upgrade the firmware before agreeing "yes the hard drive is fuxxored" and sending the replacement part. Even more ridiculous is depending on the tech they might actually ask you to update the motherboard firmware when a motherboard has failed (Um, yeah.), or the iLO firmware even though it is totally unrelated to the problem (fortunately on HP iLO/LOM updates usually don't interrupt services).

The problem with that is even though you might be able to keep the services patched (and even kernel if you use ksplice) and measure uptime in years, updating motherboard or even NIC firmware requires downtime. Even an active/active cluster can introduce down time for some users so downtime of a server is best avoided. Why update the motherboard firmware if there are no bugs blocking production or introducing security issues?

I understand why support reps go through the script and ask you to update firmware so they're dealing with what matches their one test system in their lab, but if it worked as deployed for months or years with the older firmware until the HDD or card croaked, why require a firmware update to a known-stable system before agreeing "Yup, $foo has failed, I'll dispatch a rep with the FRU within four hours" even when S.M.A.R.T reports a hugeassed list of errors, or it's simply not even powering up?

As far as drive firmware goes, I've had to update firmware only twice: once on an SSD, and once on Seagate drives which would freeze during recalibration, which would break arrays (I think it was the infamous 1.5TB drives but it's been a while).

Re:We need hardware write-protect for firmware

[Solandri]

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.

I've wondered why we don't do the same thing for HDD data. I bought an early SATA-USB 3.0 adapter which turned out to be a forensic tool for law enforcement. There's a jumper on it which can make the HDD read-only.

What if you could set up your website, physically move a jumper to make the HDD containing the web server and website read-only (log files and database writes should be going onto another drive on another system anyway to prevent tampering). If someone manages to get in via a vulnerability, there's no way to change the web server's configuration to give you full root. You can only access what the vulnerability allows you to access, which is usually just a small bit of memory.

Real website updates would become a lot harder. You couldn't just login to tweak a few things. You'd have to move to a more regimented model like software releases, where you put a bunch of updates and bugfixes together, test the crap out of them, then authorize it for release. Then maybe you'd send someone over to the hosting company with a flash drive with the changes to perform an update (and physically move the HDD's jumper while doing so). Yeah it's a PITA, but if there's one thing I've learned, good security and easy to use are usually mutually exclusive.

Re:We need hardware write-protect for firmware

[Anonymous Coward]

Flash drives for "secure" updates??

You need to Google that topic with "bunnie huang flash drive security", and check the first (ATM) hit: http://www.bunniestudios.com/blog/?p=3554

Another one of Bunnie's reports I recall reading on this subject mention finding small electronics dealers in (Red) China, IIRC, taking advantage of this type of hack to reprogram lower capacity flash drives to report higher, fictitious capacities - eBay has loads of them for sale "cheap, from China".

And with those exploits from the heart of Red China, it is not hard to believe that western military procurements have run into batches of hacked and/or counterfeit "MilSpec" electronics with potential call-home and command-and-control backdoors. It is definitely that old Mad Magazine "Spy vs Spy" cartoon scenarios in the real world, not just NSA/GCHQ.

I am thinking Snowden's revelations pointed out similar techniques on the NSA side.

fuggeddaboutit

RO

Re:We need hardware write-protect for firmware

[jeff4747]

power on, flash your firmware

From what? You saved it to some local storage, where it can be modified. For example, you saved it to your hard disk which you now are attempting to re-flash. But the hard disk was infected. It detects that you ware writing a firmware image to the disk, and injects itself into the new firmware image.

Firmware malware is not a trivial undertaking. So we're talking about extremely extensive effort by people who can develop very sophisticated attacks. You can't expect that they would leave any "easy" way of removing the malware open.

Re:We need hardware write-protect for firmware

[Burz]

A: Use an OS that cordons off any possibility of accessing the HD or other firmwares to begin with. The Xen hypervisor prides itself on being more secure than most, and its only about 1MB in size. Using that small and hardened attack surface as the gatekeeper to all hardware functions (including NIC and graphics), and as the means of silo-ing one's computing life into work, personal, misc online, etc., its perhaps the best defence out there for PCs. The Qubes GUI even lets you sequester USB controllers inside specific VMs and as such its a line of defence against badUSB. To top it off, it gives you facilities like splitGPG, isolated TorVM, and a means of sanitizing pdfs.

Even if you only use it to separate "online" from "offline" stuff (or even if you only use it as an untrusted "online" system), Qubes will protect the core system such as BIOS and other firmware.

FWIW & BTW, I've read parts of the OPAL 2 spec. for hard drives that states a drive manufacturer should make functions like firmware update conditional on successful authentication (no firmware update without the correct password). But it isn't clear to me whether OEMs are complying with what appears to be a recommendation.

OTOH, you could get a high-security flash drive (the kind with signed updates or read-only firmware) then put your Qubes boot partition on that and enable the Anti-Evil-Mail feature. I think Kanguru and IronKey are two such drive vendors.

Re:We need hardware write-protect for firmware

[Burz]

(Oops, that should read "Anti-Evil-MaiD feature.")

Re:We need hardware write-protect for firmware

[bored]

Unless the virus is resident in Bios... before booting into your OS.

Well, for this to work, you had better have jumpers on all your PCI/thunderbolt/etc devices with option ROMs as well. Otherwise your BIOS is going to get owned during POST.

But, all that was a fine plan before we got EFI stuffed down our throats. Now you better make sure to unplug whatever device holds the EFI System Partition as well. Because you may be loading EFI "drivers"/etc from there.

But there is a gocha there too, because lots of machines now have the primary storage soldered to the mainboard...

Re:We need hardware write-protect for firmware

[lucien86]

I'm working on the design of a Strong AI system - its security will not be unlike what you describe.. Ultra secure but a massive pain to use. Any breach in security and the machine shuts down and must be returned to a secure servicing site before it can be restarted.
Of course Strong AI also has a wonderful security get out, if it gets hacked it could be used as a weapon to kill people. This A lists any potential hacker as a terrorist, B anyone who wants a back door would have to sign a security liability waiver, C the system already has to be designed to allow cooperation with authorities, giving them power but with limitations and keeping them outside the inner security loop.

Just like with HD firmware our biggest security vulnerability will almost certainly be malware in the hardware components and their firmware.. The ideal solution is to have a secure FAB and make your own chips - if only it wasn't so ridiculously expensive..

Re:We need hardware write-protect for firmware

[jeff4747]

Because humans do not write perfect software. In addition, people are willing to aid spy agencies for money.

Re:We need hardware write-protect for firmware

[balbus000]

Aren't most motherboards sort of like this now? They come with a dual bios, one of which is read-only. If something happens to your writable bios, you boot from the read-only and copy it over to the writable bios, and then reboot from the writable one.

NSA is well-managed? Wildly unrealistic.

[Anonymous Coward]

This is professional spyware tailored for government and industrial espionage, and likely to have very selected targets.

Professional? No contractor could possibly take the spyware, as Edward Snowden did of an enormous number of records?

News stories seem to assume that the NSA is well-managed, but secret agencies have secret management. Managers of secret agencies can keep their mistakes and bad management secret.

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

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

[Smallpond]

That's a great article. So to answer the question in the summary, the way to verify your firmware is:

        Buy an identical replacement drive
        Use the vendor tool to install the same firmware version
        Use the tool described in the article to read the firmware from each drive over JTAG
        Compare the two copies to see if the suspect drive has been modified.

Doable

[sshir]

Actually, writing a verification firmware is possible (assuming, that it was written after attacking code was written and writer was not NSLed)
Simply because attack code doesn't know what output verification code must produce. It either must execute new code (will be busted) or not (will be busted). Putting a full blown interpreter (or some trap mechanism on flash access) will screw timing - again it will be busted.

Re:Doable

[sshir]

Replying to myself: actually one can easily exploit embedded flash size limitation. Simply make new firmware huge and uncompressable. Attacker will ran out of place to hide (without creating timing side effects e.g. storing stuff on platters)

Re:Doable

[Ben Hutchings]

In many hard drives the flash only has the first stage of the firmware, while the rest is on the disk - and there's lots of spare space there.

Re:Doable

[guruevi]

And how would you do that? You can fill it with junk, but then an attacker can just hide among the junk. Or you could put very bad, lengthy versions of your program in there but then that would make your program slow and cumbersome to use, debug and troubleshoot. You'd actually possibly create more attack vectors trying to fill in blank space.

Re:Doable

[jeff4747]

Simply because attack code doesn't know what output verification code must produce.

Why? To create the malware, they most likely reverse engineered the old firmware. So they know what verification code they must return.

The solution

[drolli]

should be that firmware is firmware. Please test rudimentary blocks of computing devices before you produce 100 of millions of a series.

I expect the manufacturer actually does something like a read/write test for typical conditions.

I may even accept or wish to get HDs which are one year behind SOTA, if they were not pushed out of the door in whatever shape the SW is due to a marketing deadline.

For such device i happily would pay more, if the "programmable" fuses are set/burnt.

Re:The solution

[drolli]

The difference is that if NSA manipulates all hardrives, that would be easier to spot. I know that some organizations actually check the firmaware of devices before they use these.

By the non-buy list of the

If they do do what they did up to now (namely patching some high-profile targets) it wil ltake years before it is discovered and analyzed.

Re:The solution

[Agripa]

How does making the firmware non-writable protect against the No Such Agency simply inserting their code into the original firmware in the first place - along with gagging the manufacturer and requiring them to keep the presence of this added code secret?

Are they going to gag anybody who discovers that the manufacturer was complicit in allowing the NSA or any other agency to do this? Proof would be available to anybody capable to downloading the firmware image from the product and it only takes one person to discover and advertise the truth.

Then what happens to the reputation of the manufacturer when faced with undeniable proof that they did this? The government can grant then immunity from civil lawsuits like they did with the telecommunication companies but are they going to mandate that others continue to buy their products?

Do you trust the company?

[Anonymous Coward]

Look at the Dells that were bootjacked by the NSA. Dell had likely provided the source code to the bios to the NSA for approval for government work, and as a result, Dells BIOS got some unwanted extra NSA code which let NSA take control of Dell Servers across the world.

http://www.zdnet.com/article/nsa-hacked-dell-poweredge-server-bios/

So you would likely flick the switch trusting it was Dell BIOS update yet its a BIOS update carrying spyware.

Then of course the other problem, NSA gets Fedex/UPS/TNT or others to divert a laptop to a local blacksite where the spyware is installed. Did that kit you bought online take a detour? Mine did.

http://news.yahoo.com/nsa-intercepts-laptop-deliveries-install-spyware-143011341.html

Of course any physical switch would simply be flipped for the malware install.

Re:Do you trust the company?

[drinkypoo]

So you would likely flick the switch trusting it was Dell BIOS update yet its a BIOS update carrying spyware.

Yes, the need to have some kind of open bios (coreboot? pretty lumpy process, though) is real, but that doesn't decrease the need for write protect jumpers.

Re:Do you trust the company?

[jeff4747]

Yeah, it's not like open source software like glibc was recently found to be vulnerable.....

Re:Do you trust the company?

[drinkypoo]

Yeah, it's not like open source software like glibc was recently found to be vulnerable.....

The obligatory rebuttal is obviously to question what vulnerabilities are in closed libcs that we're simply not finding? How do you know there aren't more? Sacrificed a chicken this morning?

How is a HDD firmware written?

[jones_supa]

What is the process of writing a new HDD firmware? Does the drive listen for some specific ATA command followed by the program data?

Re:How is a HDD firmware written?

[Anonymous Coward]

Depends on the drive, but what you say is one option. There is even a specific firmware update command in the ATA spec, but many vendors use their own just because.

The firmware is either stored on flash memory, or more recently, on the drive itself. Only a small bootloader is still in flash/rom of the controller.

Re:How is a HDD firmware written?

[fisted]

The firmware is either stored on flash memory, or more recently, on the drive itself. Only a small bootloader is still in flash/rom of the controller

That sounds like a chicken-egg problem. If the drive can access the platters without firmware, what's the point of the firmware then? Or if the 'small bootloader' can actually access the platters, then what does it need to read the 'real thing' from the platters for?

Re:How is a HDD firmware written?

[Microlith]

There is even a specific firmware update command in the ATA spec, but many vendors use their own just because.

Not "just because," but because the standard Download Microcode command is PIO and happens completely synchronously. This can cause Windows to BSOD if it happens to hit a page fault during the update.

Vendors typically implement an NCQ, DMA-capable process that is asynchronous so you can update from within the OS without issue.

Re:How is a HDD firmware written?

[Agripa]

That sounds like a chicken-egg problem. If the drive can access the platters without firmware, what's the point of the firmware then? Or if the 'small bootloader' can actually access the platters, then what does it need to read the 'real thing' from the platters for?

The Flash storage for the boot-loader may be too small or in the old days it would be in mask ROM. It is also likely more convenient to program the current firmware image onto the drive instead of into the Flash. The drive meta-data like the sector relocation tables have to be read in from the drive anyway.

Re:How is a HDD firmware written?

[fisted]

Thanks, but that doesn't answer (or even address) my question at all...

How much CPU power & storage in HDD controller

[swb]

How much CPU power is in HDD controllers and how big is the flash storage on the controller?

I'm mostly just curious, but I wonder how much "elbow room" there is to do something nefarious like blocking updates or protecting boot sectors without compromising drive performance significantly.

Is there a mechanism for running software on the drive controller -- passing input, getting output, etc?

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:Secure Boot + Full disk encryption

[vojtech]

Of course the UEFI code cannot bypass the drive firmware. From the point of view of secure boot, the boot media is untrusted, and thus it doesn't care whether there is any malicious code in the drive firmware. It simply verifies that anything it loads from there is signed and thus uncompromised. If the bootloader or kernel were tampered with, Secure Boot will refuse to boot.

Re:Secure Boot + Full disk encryption

[vojtech]

Most Secure Boot implementations let you use your own keys. And building your own shim is just a matter of typing 'make'.

Re:Secure Boot + Full disk encryption

[davidshewitt]

I've actually been thinking of setting something like this up. I want to load my own key into UEFI and sign the bootloader with it. I already use LUKS. Any recommended how-to's?

Re:Secure Boot + Full disk encryption

[vojtech]

Your example #1 doesn't work. There is no point in the Secure Boot boot process which wouldn't be cryptographically verified. The shims are signed and verified, even the MOKManager is. So the malicious code can run on the drive, but will not affect what is running on the main CPU and the main CPU will not leak any key data to the drive.

For your example #2: I do not care if random bits of my encrypted data remain in a hidden part of the drive. That will happen on SSDs anyway.

Re:Secure Boot + Full disk encryption

[vojtech]

Since the CD-ROM drives today have handle many formats from old CD to latest BluRay, they have in fact a fairly capable (and upgradable, remember the region wars?) firmware and a CPU on them.

Re:Secure Boot + Full disk encryption

[vojtech]

Don't use Microsoft keys in your UEFI secure boot setup, then. Use your own.

Re:Secure Boot + Full disk encryption

[vojtech]

Blocking the firmware update command is certainly a good idea. Even if you protect your OS from malware coming from the drive, you can still have an unbootable machine, thanks to Secure Boot or completely corrupted firmware.

Re:Secure Boot + Full disk encryption

[vojtech]

I have to admit that due to where I work, I simply use openSUSE. With 13.2, it's all just a matter of selecting the right options in the installer.

Re:How much CPU power & storage in HDD control

[digitalchinky]

Have a read of this: http://spritesmods.com/?art=hd...

There is a decent chunk of compute power in the controllers.

Re:Sonic changes at boot-up

[chill]

SSDs

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:How much CPU power & storage in HDD control

[swb]

That was fascinating, thanks for the link (and the lost 45 minutes reading about the guy's other genius hacks).

Important topical idea!

[meburke]

I have long believed that if it was as hard to maintain a car as it is to administer a computer, the world would stay home and read books.

It is the manufacturers' responsibility to ensure that hardware does what it is supposed to, does it correctly, and does ONLY what it is supposed to do. In the coming age of self-driving cars, personal care robotics and so forth, it is inexcusable for the builder to make defective stuff. I suspect we will have to go back to first principles instead of relying on software recipes that were invented back in the 1960's.

We will run into another level of complexity when our machines start modifying themselves for something called "better performance."

This does not answer your question, but this is a legitimate area for concern and I thank you for bringing it up.

"Why don't these companies provide verification"

[SwashbucklingCowboy]

Because it's never been an issue before.

Seagate HDs

[BlackLotus89]

If it's about seagate hds you can take a look at seaget.With this you can dump the buffer and memory of your harddrive. Here is an explanation https://blacklotus89.wordpress... and here is the code https://github.com/BlackLotus/... Maybe this can be used to dump the firmware as well (somehow)

Re:Seagate HDs

[jeff4747]

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

FTFY.

Re:Seagate HDs

[jeff4747]

Yes, the malware would report back the values for the same image as the non-infected drives, giving you the same results as the majority.

Boot from rescue disk, inspect disk and boot proms

[davecb]

Boot from a randomly chosen Linux rescue disk, and check the various proms. You've used the boot rom to boot a CD/DVD, but what you've booted is wildly different from the Windows systems that are the common target, so the attackers will have great difficulty in hiding what they've done from an unfamiliar system.

It's actually easier to hide evil stuff in disk proms, as your only access to them is via routines *in* the disk prom, as one of the other commentators pointed out,

Re:What do HD viruses actually _do_ ?

[Etcetera]

Are these root vectors playing the odds and assuming they'll be installed on an x86 machine running Windows7, so they put that payload in the firmware?

It's not like the firmware has an IP stack.

It doesn't take very many bytes to make one. And your hard drive is communicating over a bus. You'd be surprised what types of communication protocols are recognized over various internal data paths... How do you think those old Ethernet-over-SCSI adapters worked?

Re:How much CPU power & storage in HDD control

[wvmarle]

I doubt you need much, really.

All the malware part has to do is to read the rest of the software from disk upon boot, then hide that part of the drive from the OS. This way you could hide a pretty big piece of software on the disk, and with today 500 GB kind of capacities being the norm, the user won't notice unless they look really really carefully at the numbers.

Re:bennett haselton -- what remains what he can't

[fisted]

Dear Mr. Low-ID, here's your Interwebs 101: Don't feed the trolls. That is, unless you're in for quality counter trolling.

Security by Oscurity

[ramriot]

Here is the problem:
Manufacturers guard their intellectual property fiercely, and they guard their proprietary firmware fiercest of all. Thus the API for uploading drive firmware is Write Only (WO). Thus within the existing API and interface there is by design no way to validate the firmware. What that means is that, if you are able to build your own firmware (because you have a copy of the source, obtained deviously) then you can alter it to your own ends and even make it so that the (WO) overwrite API does nothing.

Outside of the existing interfaces though you can with sufficient skill get some knowledge. If the firmware is stored on a flash chip separate from the drive CPU you can get a copy of the microcode by probing the chip directly either during read cycles with the drive active or by controlling the chip fully with the drive off. Unfortunately you cannot do this so easily if the firmware is stored in flash within a drive micro-controller. As to JTAG, that may or may not work because in production a manufacturer may choose to disable that interface to prevent competitors doing exactly what you are wanting to do.

In Summary, you are SOL unless manufacturers rewrite their firmwares to add a secure means of proving firmware validity, and don't ask me how.

Re:Security by Oscurity

[Burz]

I'm glad someone made a point about security by obscurity.

The OPAL 2 spec. does mention guarding firmware updates in section 5, but it does not appear to be compulsory (and no one I'm aware of from the HD industry has said anything yet...).

MOD PARENT UP

[lhaeh]

MOD PARENT UP

Re:Not considered a real risk - at least, until no

[qpqp]

So, you're saying that it's so simple to get SHA256 collisions that thousands of people getting sued for torrenting can fuck these copyright companies right over?
I don't think I quite believe you and last time I checked I needed quite a server farm to (reliably) produce one collision in a meaningful amount of time.

Hashes can be useful.

[Ungrounded Lightning]

Which is why I always laugh my ass off at all these people who use PGP to sign things and put a hash on the same website you download it from ... look you can verify this file you downloaded from the website hasn't changed because theres no way anyone would be smart enough to update the hash as well!

That's why you SIGN the hash. Then only the public key needs to be published by a different route.

And it doesn't HURT to publish it on the web site as well: Then someone tampering by substituting a different public key sets off alarm bells when that differs from the public key obtained from another site or by another path. Blocking that makes man-in-the-middle more complex: The attacker has to have essentially total control of the path to the victim and be able to recognize and substitute the public key whenever it shows up. One slip-up and somebody may raise the alarm.

Meanwhile: Even if publishing hashes on the same site may not provide additional security against MITM, it DOES let you check the download wasnt corrupted in transit (in ways other than malicious substitution). With modern protocols that's less of a problem these days than it used to be, but a check would be comforting.

Or the malware might cover its tracks.

[Ungrounded Lightning]

If you ask the drive to read out the whole flash.
The maybe the firmware would have to go to the platter to get the real image.

Or the malware could regenerate the un-attacked version.

For instance: If it's a patch that loads into an otherwise cleared-to-known-vallue region it can detect that region while reporting flash content and report the cleared value, instead. Add a couple other tiny regions where it saved (or alread knew) the previous contents where it "sank it's hooks" and you can't tell it's there from its replies to dump requests.

JTAG seems safer.

Yep. JTAG, in principle, could be corrupted. But it would require substantial hardware support that almost certainly isn't there (yet!)

Re:Or the malware might cover its tracks.

[Ungrounded Lightning]

I mean if they go to the trouble to do this why do it in a way that would be discoverable via jtag for other state actors. I mean if they go to the trouble to do this why do it in a way that would be discoverable via jtag for other state actors.

Because hacking the JTAG to hide malicious hacking of the software is a massive endeavor and a massive PITA.

Besides, if they built it into the original software they wouldn't NEED to hack the JTAG to hide it. The code would match the released version. (You'd have to reverse-engineer it to discover their back doors.)

I guess the real question is:

[JustNiz]

Do you think an infection would be more likely to come from hackers that somehow modified the drive after the manufacturer shipped it, or do you think it is more likely that the NSA (or whoever) already work with the manufacturer?

If the latter, chances are the option with least security risk is to not update it at all, especially if its an older drive.

We need more than hashes to verify "integrity"

[Anonymous Coward]

We need the actual sources and currently there are very few companies who have done this for even some chips. I can literally count on one hand the number chips with whoms code has been released. AR9271, AR7010+AR9280, AR9170. There is one other I believe for which I'm leaving out as I forget what it is. There are sources for at least one or two reverse engineered chips too I believe.

Sadly the responses you'll get if you inquire are “what do you need that for” and “there are so many other places with proprietary code its utterly pointless”.

The problem with this thinking is its not pointless. We simply have to work toward getting companies to release more code than they currently do. Getting sources released for a stage-one bootloader might not be significant in and of itself, but it is a start. Right now we can't really design one good system where all the sources are available because there are components where there aren't any options where the complete set of sources is available. Short of leaving those components out you probably won't be able to do it right now. You can essentially say that no individual or state is secure. Period.

What people are forgetting is that there are numerous state adversaries whom are actively attacking our security. Even if you aren't concerned with the US government you should be concerned with security in general. There are near 200 states all of which could be significant adversaries not to mention other non-state actors. There are numerous criminal organizations, corporations, resistance groups, and drug kingpins all of whom would love such vulnerabilities and/or backdoors.

With some performance compromises we're not that far off from having secure computing options. Give enough interest and in a few years we could do it.

row:how ?

[ArcadeMan]

if that's been tampered with there's no way you can be sure.

Nuke it from orbit. It's the only way to be sure.

Re:Boot from rescue disk, inspect disk and boot pr

[jeff4747]

Boot from a randomly chosen Linux rescue disk, and check the various proms.

And those proms are read by the firmware in those proms. Why does the firmware have to respond with what is actually running?

Used to be NSA ...

[perpenso]

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

Not really, it may have once been NSA but once the code was discovered it could be anyone using it. It just becomes another "tool" in the "public" toolbox.

Re:Not considered a real risk - at least, until no

[ckatko]

Just because you don't understand something doesn't mean it doesn't happen. It means you don't understand. The mere fact you didn't know firmware was upgradable means you are unqualified to tell us things aren't a big deal.

Re:Not considered a real risk - at least, until no

[Immerman]

Depends on the checksum - I understand the better ones like SHA and maybe even MD5 are relatively irreversible, making them extremely difficult to spoof. Yes, you could do it if you had enough resources to throw at the problem, but I'm betting even the NSA probably has better things to do with their computation centers that week (month? year?). Sure, SHA-1 is only 160 bits, but that's still 10^48 possibilities, and you'll have to recompute the hash with a sizable fraction of that many different fillers to get a false-match.

Non-persistance is the only solution

[WaffleMonster]

The best we can hope for is systems offering assurances they can be restored to their initial state. The only way to do this is for hardware to physically lack any means of remembering.

Re:Not considered a real risk - at least, until no

[wvmarle]

If you don't have proper reading comprehension skills, you are unqualified to reply.

No-where did I try to say it's not a big deal.

Re:Boot from rescue disk, inspect disk and boot pr

[davecb]

Only on-disk, non-addressable controller proms are "read" by the software in the proms.

The boot prom has to boot stuff or the product can't be sold, and in this case is used to boot a program that runs on the hardware that continuously reads the prom. That HW can verify it, and all the other proms which are reachable from the CPU, including all sorts of stuff plugged into the various busses. That includes some disks, the ones we were worried about viruses wiping.

For some specific disks, you may have to pull the drive and clamp directly to the prom's pins.Those are the ones a spy would want to subvert.

Open source hard drive firmware

[Futurepower(R)]

We need open source hard drive firmware.

We also need open source integrated circuits.

physical switch

[pikine]

Even so, having a physical switch is already helpful. I don't need to worry about the firmware malware if I don't ever have the intention to flip the switch. I only need to take measures to secure the computer against the malware if I plan to flash the firmware. A physical switch is a very powerful countermeasure to thwart remote attackers. U2F tokens also use it to secure two-factor authentication.

Couldn't this be handled with dual firmware?

[King_TJ]

I'm thinking this might be similar to what some of the video card manufacturers have done (such as with the R9280X cards), where a physical DIP switch on the card selects between firmware flash A or B. If you suspected corruption, you could flip the switch to use the alternate, which presumably would be loaded from the factory with good, working firmware of whatever version was most recent at the time the product was manufactured.

I suppose this would technically only give you "one shot" at recovering from a firmware hack ... but better than nothing, right? And in the meantime, it would give protection to people from such things as a corrupt flash update or a way to do an easy A/B comparison between 2 firmware revisions.

Keep hard drives outside of your circle of trust.

[craighansen]

If you cannot audit the source code of the hard drive firmware, you must keep hard drives outside of your circle of trust. That means that all hard drive traffic should be encrypted with keys not available to the hard drive. Digital signatures and time stamps can also be employed to ensure that the drive isn't utilizing replay attacks or swapping blocks around. As a bonus, this protects against failures in the transmission path, in even stronger ways than ZFS uses checksums. And remember, once you're out, you're out. There's no coming back.

Re:What does the compromise do

[craighansen]

When the code executing the CPU resides on the hard drive, compromising the hard drive gives you everything. In addition, hard drive controllers and network controllers could be compromised to provide direct leak paths without involving the CPU using DMA.

Re:How much CPU power & storage in HDD control

[thogard]

There is enough flash and ram to run Linux on the controller. I've seen it done at Ruxcon/Breakpoint where the hard drive booted up to the point where it couldn't find a root disk to mount.

It is trivial to make firmware that watches for things like /etc/shadow files and returns something else. You can have this code activate by searching for data that would be logged and hunting for the magic key and that is trivial since every system logs to disk.

Re:What do HD viruses actually _do_ ?

[AHuxley]

Re "Basically the keys to the castle without presenting any evidence that your doors are all open. as useful if not more so than UEFI takeover."
Ready to go after any wipe or AV or heuristics, behavioral analysis. Collecting data and waiting for a network or usb stick out.

Downloads, yes, installed firmware, no

[davidwr]

For downloads of updates, yes, checksums and the like can and probably should be widely published. As others have said, having the checksums ONLY on the vendor's web site probably isn't any good but if they were "all over the web" they would essentially be tamper-proof.

Better than a checksum would be a cryptographicly signed by a public key that was issued by a major company that you trust already.

As far as the firmware that is on the drive:

Unless you have a way of directly reading the firmware memory without using the firmware itself, forget about it. Any attempt to ask compromised firmware to give you a data dump of itself would likely just get it to lie to you. Yes, there is probably equipment out there that can read the chips but you probably don't have it and you probably can't afford it unless you are doing it as a business or as part of a larger business (such as computer manufacturing, where you may want to validate that OEM drives contain the firmware that should be on them and not the ones that $SPYING_GOVERNMENT_AGENT installed).

My firmware

[phorm]

Just checked, apparently mine is version

WD-3.02.6-NSA-1

Re: Disable jumper

[Agripa]

The simple solutions are the best a WP jumper for the flash. How hard could that be?

This used to be easy because the write protect switch could operate either through the high voltage programming supply or the write strobe. Internal charge pumps have obviated the need for an external high voltage programming supply and embedded Flash has no write strobe to access.