Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
Data Storage Security

Ask Slashdot: How Does One Verify Hard Drive Firmware? 324

Posted by Soulskill from the very-carefully dept.
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.
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Does One Verify Hard Drive Firmware? More

Ask Slashdot: How Does One Verify Hard Drive Firmware?

Comments Filter:

  • how ? (Score:5, Insightful)

    by itzly ( 3699663 ) on Sunday March 01, 2015 @06:50AM (#49157765)

    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 ? (Score:5, Insightful)

      by storkus ( 179708 ) on Sunday March 01, 2015 @07:06AM (#49157813)

      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 ? (Score:4, Insightful)

        by Anonymous Coward on Sunday March 01, 2015 @08:48AM (#49158015)

        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.

      • 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 los

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

          • 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 che

        • 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 ? (Score:4, Interesting)

          by AK Marc ( 707885 ) on Sunday March 01, 2015 @02:28PM (#49159129)

          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: (Score:2)

        by Greyfox ( 87712 )
        Feel free to put a feature request in with the NSA to please make their viruses easier to spot in the future.

      • Re: (Score:2)

        by eth1 ( 94901 )

        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 i

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

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

  • 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 be

    • Re:Almost impossible (Score:5, Insightful)

      by itzly ( 3699663 ) on Sunday March 01, 2015 @07:13AM (#49157839)

      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.

      • 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: (Score:2)

        by ponos ( 122721 )

        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.

  • 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 calc

  • Hashes not useful (Score:5, Informative)

    by IamTheRealMike ( 537420 ) on Sunday March 01, 2015 @06:54AM (#49157781)

    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

    • 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 (Score:4, Interesting)

        by itzly ( 3699663 ) on Sunday March 01, 2015 @08:03AM (#49157921)

        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.

      • 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: (Score:3)

        by amck ( 34780 )

        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: (Score:3)

          by Splab ( 574204 )

          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.

        • 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 secu

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

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

      • 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 p

    • Re: (Score:2)

      by hey! ( 33014 )

      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 (Score:4, Informative)

      by bill_mcgonigle ( 4333 ) * on Sunday March 01, 2015 @12:43PM (#49158717) Homepage Journal

      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.

      • 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 runnin

  • Pretty pointless (Score:5, Interesting)

    by rainer_d ( 115765 ) on Sunday March 01, 2015 @07:10AM (#49157833) Homepage
    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 (Score:5, Interesting)

      by Anonymous Coward on Sunday March 01, 2015 @10:14AM (#49158249)

      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.

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

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

        • 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 (Score:5, Insightful)

      by bill_mcgonigle ( 4333 ) * on Sunday March 01, 2015 @12:50PM (#49158741) Homepage Journal

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

      Dude, you're fourteen years behind [wikipedia.org] the news. The technique is not to get you on the "refusing NSA" charge, but any of the other countless criminal acts [amazon.com] 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 [econlib.org].

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

  • We need hardware write-protect for firmware (Score:5, Insightful)

    by jonwil ( 467024 ) on Sunday March 01, 2015 @07:53AM (#49157911)

    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.

    • 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: (Score:2, Interesting)

      by 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: (Score:3)

      by gnupun ( 752725 )

      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 (Score:5, Informative)

        by alphatel ( 1450715 ) * on Sunday March 01, 2015 @08:30AM (#49157979)

        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: (Score:3)

          by gnupun ( 752725 )

          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.

        • 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 th

      • Re: (Score:2)

        by MrKevvy ( 85565 )

        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.

        • SSD's firmware get many necessary updates.

        • 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 usuall

      • 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-fl

      • Re: (Score:3)

        by hey! ( 33014 )

        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 *outs

    • Re: (Score:2)

      by davecb ( 6526 )
      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

    • 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 ma

  • Doable (Score:3)

    by sshir ( 623215 ) on Sunday March 01, 2015 @08:21AM (#49157963)
    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: (Score:3)

      by sshir ( 623215 )
      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)

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

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

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

  • How much CPU power & storage in HDD controller (Score:3)

    by swb ( 14022 ) on Sunday March 01, 2015 @08:57AM (#49158043)

    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?

    • Comment removed based on user account deletion

      • Re: (Score:2)

        by swb ( 14022 )

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

    • Re:How much CPU power & storage in HDD control (Score:4, Insightful)

      by GrangerX ( 1959200 ) on Sunday March 01, 2015 @10:02AM (#49158205)

      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.

    • 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: (Score:3)

      by thogard ( 43403 )

      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.

  • Secure Boot + Full disk encryption (Score:5, Insightful)

    by vojtech ( 565680 ) <vojtech@suse.cz> on Sunday March 01, 2015 @09:10AM (#49158067)

    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.

  • 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

  • Because it's never been an issue before.

  • Seagate HDs (Score:3, Informative)

    by BlackLotus89 ( 2530144 ) on Sunday March 01, 2015 @10:49AM (#49158357)
    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... [wordpress.com] and here is the code https://github.com/BlackLotus/... [github.com] Maybe this can be used to dump the firmware as well (somehow)

  • 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,

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

  • 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 doe

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

Slashdot Top Deals

Real programmers don't write in BASIC. Actually, no programmers write in BASIC after reaching puberty.

Close