3 ms·

This is just a special case of the fact that there's no secure anything. In 2016 that's just the price you pay for using computers. You just have to live with

This is just a special case of the fact that there's no secure anything. In 2016 that's just the price you pay for using computers. You just have to live with it. Mitigate it the best you can, rely on the ol' "mossad or not mossad" strategy now and then, hope for the best, etc. If you have a strong need for increased security, well, god help you (spoilers: you will receive no help), you're going to pump a lot of effort into building something that will still have tons of vulnerabilities.

zanny 11y ago
Just get an FSF laptop for security. You can even trust the hard drive if you use software encryption of all your data. I'm not sure what remains insecure on that class of hardware?
- schoen 11y ago
  They have a better story about firmware than other devices, but they're still running Linux and GNU software, which often has remotely exploitable vulnerabilities. Just today OpenSSH (which is neither Linux nor GNU but which you would obviously use on your FSF laptop) announced an extraordinarily serious remotely exploitable vulnerability. That's presumably not the last vulnerability of that severity in an operating system you install today onto your FSF laptop. It's not obvious that FDE will totally mitigate hard drive firmware attacks because your boot loader and kernel are likely running from an unauthenticated partition (for instance, most Linux-based systems with LUKS today have all of /boot on a separate non-LUKS partition, and something like a GRUB boot sector too). If the hard drive understood how to recognize the kernel in /boot, it could inject a vulnerability into it. In a few presentations a couple of years ago, I walked through a real example of how a single bit flip in a binary can introduce (or re-introduce) a fencepost error that can compromise security, because the opcodes for extremely similar yet different conditional branches often differ by a single bit. One form of the conditional branch like jump-if-less may be the correct invariant, while another form like jump-if-less-or-equal may be the exploitable erroneous form of the same loop. I'm not knocking people's work on trying to get a handle on what firmware is running on their devices; I think that work is great. The trouble is that attackers are looking for exploits and persistence in every layer of the system, so you won't get a silver bullet against all attacks by shoring up one aspect. Good stuff on this: Halvar Flake's "Why Johnny Can't Tell if He is Compromised", and Joanna Rutkowska's recent CCC presentation on persistent state.
- throwaway7767 11y ago
  > You can even trust the hard drive if you use software encryption of all your data. Hard drive replaces your GRUB payload with a compromised one that records your encryption key. You lose. You could put your bootloader and /boot on a USB stick, but then you're putting the same trust in the stick. Unfortunately, hardware security is really difficult if your threat model does not assume your vendors are trusted. In fact, I don't think it's actually possible today to get verifiably trustworthy hardware under that threat model.

zanny 11y ago

Just get an FSF laptop for security. You can even trust the hard drive if you use software encryption of all your data. I'm not sure what remains insecure on that class of hardware?

schoen 11y ago
They have a better story about firmware than other devices, but they're still running Linux and GNU software, which often has remotely exploitable vulnerabilities. Just today OpenSSH (which is neither Linux nor GNU but which you would obviously use on your FSF laptop) announced an extraordinarily serious remotely exploitable vulnerability. That's presumably not the last vulnerability of that severity in an operating system you install today onto your FSF laptop. It's not obvious that FDE will totally mitigate hard drive firmware attacks because your boot loader and kernel are likely running from an unauthenticated partition (for instance, most Linux-based systems with LUKS today have all of /boot on a separate non-LUKS partition, and something like a GRUB boot sector too). If the hard drive understood how to recognize the kernel in /boot, it could inject a vulnerability into it. In a few presentations a couple of years ago, I walked through a real example of how a single bit flip in a binary can introduce (or re-introduce) a fencepost error that can compromise security, because the opcodes for extremely similar yet different conditional branches often differ by a single bit. One form of the conditional branch like jump-if-less may be the correct invariant, while another form like jump-if-less-or-equal may be the exploitable erroneous form of the same loop. I'm not knocking people's work on trying to get a handle on what firmware is running on their devices; I think that work is great. The trouble is that attackers are looking for exploits and persistence in every layer of the system, so you won't get a silver bullet against all attacks by shoring up one aspect. Good stuff on this: Halvar Flake's "Why Johnny Can't Tell if He is Compromised", and Joanna Rutkowska's recent CCC presentation on persistent state.
throwaway7767 11y ago
> You can even trust the hard drive if you use software encryption of all your data. Hard drive replaces your GRUB payload with a compromised one that records your encryption key. You lose. You could put your bootloader and /boot on a USB stick, but then you're putting the same trust in the stick. Unfortunately, hardware security is really difficult if your threat model does not assume your vendors are trusted. In fact, I don't think it's actually possible today to get verifiably trustworthy hardware under that threat model.