4 ms·

eSata itself is not vulnerable. The sata lanes themselves have no DMA, it's the controller where the DMA requests are generated, so a malicious hard drive on it

eSata itself is not vulnerable. The sata lanes themselves have no DMA, it's the controller where the DMA requests are generated, so a malicious hard drive on its own would not be able to compromise a computer. I guess it's conceivable that some three-letter agency has hacked together some hard drive that can compromise a specific chipset, but at that point, it becomes a lot easier to just present a compromise in the filesystem of the hard drive, because filesystem drivers are entirely too easily confused by bad data, such as http://www.spinics.net/lists/linux-ext4/msg47160.html http://www.spinics.net/lists/linux-ext4/msg47160.html

mschuster91 12y ago
> I guess it's conceivable that some three-letter agency has hacked together some hard drive that can compromise a specific chipset I was more thinking of Linux or Windows hardware driver level compromises, as a filesystem exploit requires that the drive in question is actively mounted and a protocol driver exploit pwns your system as soon as you attach the drive. Combine a OSX, a Linux and a Windows exploit in the ATA protocol drivers and you have a cyberweapon capable of infecting even a forensic analysis system. And in contrast to USB, I don't believe that ATA and other low-level hardware protocol implementations in kernels get very much attention from developers. Forensic imagers are pretty much standard equipment in any police lab, but I doubt that a normal investigator will disassemble a disk and do raw forensics on the disk platters... heh, if I were a guy with something to hide, I'd hack the firmware to either wipe the disk upon imaging or compromising the investigator's machine.
- bigiain 12y ago
  You've seen Travis Goodspeed's work there? http://events.ccc.de/congress/2012/Fahrplan/events/5327.en.html http://events.ccc.de/congress/2012/Fahrplan/events/5327.en.h... https://www.youtube.com/watch?v=D8Im0_KUEf8 https://www.youtube.com/watch?v=D8Im0_KUEf8 It's _really_ nice...
  - mschuster91 12y ago
    Oh indeed. I did not know about this, thank you very much. I came up with yet another, truly weird plan. Take a 2-platter disk with 500GB (so 250GB per platter), scratch off the label. Modify the firmware so that: a) both platters are encrypted with a hardcoded, generated-at-lowlevel-reformat secret key to delay forensic efforts b) the ATA identify and other ID values point to a 250GB drive (half the original capacity!) c) the bootloader is two-staged, boot0 running on the HDD CPU and boot1 running on the host before the OS bootloader. If e.g. a specific key is pressed during boot, boot1 asks for a password and gives this password to boot0 (e.g. via custom ATA command). boot0 now uses this password to apply a second decryption to platter1 - so there is no TrueCrypt or anything on the "hidden" OS which impacts performance (you can reveal if you're using TrueCrypt via a sidechannel attack. Determine the HDD model and compare write speed with a reference value. If you're inside spec - no crypto. If you're slower - crypto). If no key is pressed, then boot0 boots the bootloader from the unlocked platter2 - the "clear" OS will have no way of seeing the data on platter2 and even if the reported HDD size is compared with the specifications of the (manipulated!) HDD model name as reported to the OS, a malware has no way of knowing that this HDD in fact has a hidden area.
    - rasz_pl 12y ago
      1/ This is pretty much how for example Seagate refurbishes drives (or used to). They disable whole bad platters in firmware, rewrite drive capacity, slap REFURB sticker and send drive back as a replacement for smaller one. 2/ you can do this _yourself_ today on off the shelf drive using HPA/DCO 3/ Dont really understand your plan, you want to prepare drive like that to hide your own data from others? average foresic investigator will immediately tell your 'clear' OS is an unused decoy (no signs of regular daily use).
      - mschuster91 12y ago
        ad 3) indeed, you're right. Better idea: make the firmware act like a SATA hub and pretend two different disks (of course, the "second" disk is only visible after unlocking at boot time). This way, OS is used regularly - and all evidence on the system will point to an USB stick or eSATA disk being used.

mschuster91 12y ago

> I guess it's conceivable that some three-letter agency has hacked together some hard drive that can compromise a specific chipset I was more thinking of Linux or Windows hardware driver level compromises, as a filesystem exploit requires that the drive in question is actively mounted and a protocol driver exploit pwns your system as soon as you attach the drive. Combine a OSX, a Linux and a Windows exploit in the ATA protocol drivers and you have a cyberweapon capable of infecting even a forensic analysis system. And in contrast to USB, I don't believe that ATA and other low-level hardware protocol implementations in kernels get very much attention from developers. Forensic imagers are pretty much standard equipment in any police lab, but I doubt that a normal investigator will disassemble a disk and do raw forensics on the disk platters... heh, if I were a guy with something to hide, I'd hack the firmware to either wipe the disk upon imaging or compromising the investigator's machine.

bigiain 12y ago
You've seen Travis Goodspeed's work there? http://events.ccc.de/congress/2012/Fahrplan/events/5327.en.html http://events.ccc.de/congress/2012/Fahrplan/events/5327.en.h... https://www.youtube.com/watch?v=D8Im0_KUEf8 https://www.youtube.com/watch?v=D8Im0_KUEf8 It's _really_ nice...
- mschuster91 12y ago
  Oh indeed. I did not know about this, thank you very much. I came up with yet another, truly weird plan. Take a 2-platter disk with 500GB (so 250GB per platter), scratch off the label. Modify the firmware so that: a) both platters are encrypted with a hardcoded, generated-at-lowlevel-reformat secret key to delay forensic efforts b) the ATA identify and other ID values point to a 250GB drive (half the original capacity!) c) the bootloader is two-staged, boot0 running on the HDD CPU and boot1 running on the host before the OS bootloader. If e.g. a specific key is pressed during boot, boot1 asks for a password and gives this password to boot0 (e.g. via custom ATA command). boot0 now uses this password to apply a second decryption to platter1 - so there is no TrueCrypt or anything on the "hidden" OS which impacts performance (you can reveal if you're using TrueCrypt via a sidechannel attack. Determine the HDD model and compare write speed with a reference value. If you're inside spec - no crypto. If you're slower - crypto). If no key is pressed, then boot0 boots the bootloader from the unlocked platter2 - the "clear" OS will have no way of seeing the data on platter2 and even if the reported HDD size is compared with the specifications of the (manipulated!) HDD model name as reported to the OS, a malware has no way of knowing that this HDD in fact has a hidden area.
  - rasz_pl 12y ago
    1/ This is pretty much how for example Seagate refurbishes drives (or used to). They disable whole bad platters in firmware, rewrite drive capacity, slap REFURB sticker and send drive back as a replacement for smaller one. 2/ you can do this _yourself_ today on off the shelf drive using HPA/DCO 3/ Dont really understand your plan, you want to prepare drive like that to hide your own data from others? average foresic investigator will immediately tell your 'clear' OS is an unused decoy (no signs of regular daily use).
    - mschuster91 12y ago
      ad 3) indeed, you're right. Better idea: make the firmware act like a SATA hub and pretend two different disks (of course, the "second" disk is only visible after unlocking at boot time). This way, OS is used regularly - and all evidence on the system will point to an USB stick or eSATA disk being used.