4 ms·

I’ve never seen a big problem with things like SSDs or sensors and likewise parts having their own blobs. Sure, it’d be nice if you can poke around in them, but

by jorvi 5y ago

I’ve never seen a big problem with things like SSDs or sensors and likewise parts having their own blobs. Sure, it’d be nice if you can poke around in them, but they don’t have DMA and they have no way to communicate with the outside world. It’s as if you put a untrustworthy guy on a really far away island and occasionally go to him and ask him what the temperature is. He has no way to observe what is happening on the mainland, and even if he did he has no way to talk to anyone about it.

dmos62 5y ago
Could a rogue SSD move things around in your filesystem? If so, couldn't it install a rootkit? Either way, it's not just about backdoors. A blob is like a car that you cannot perform maintenance on. You want to be able to fix bugs, and also inspect it to check if there aren't any. Maybe customize it.
josephg 5y ago
Hmm, I’m not sure I agree. Malicious firmware blobs in your disk controller could do all sorts of damage, like silently replacing parts of executable files with whatever they like. Someone made a proof of concept of this a few years ago - where they managed to replace some of the controller firmware in a hard disk. Their modified drive would then silently replace a certain executable with something else. And on that drive, the attack was persistent. And are modern NVMe drives isolated? Is your system secure if you have a malicious PCIe device attached? (Even if disk controllers are isolated, are graphics cards? Couldn’t my NVMe drive just claim to be a GPU and DMA all it likes?)
- 3np 5y ago
  Full-disk- or file-system-level encryption on everything reduces the impact by a lot.
  - flyingfences 5y ago
    How is the full-disk encryption implemented? Not by the disk, I hope.
    - anthk 5y ago
      In OpenBSD, for example, in software.
    - 3np 5y ago
      Naturally. LUKS or ZFS native encryption, for example.
- mywittyname 5y ago
  This is pretty nifty, but I have to imagine that it is also detectable if you look for it. The drive can't differentiate between being read for execution and being read for analysis. So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change. Such a program could be injected into the firmware of the machine, so it will never be read from disk, and it is unlikely need updating. One could also produce a second, clean room, program which does the same thing. This could serve as a back up in case a buffer overflow or similar exploit is found and leveraged in the first validation program. Additionally, without the ability to self-update its signature database, version updates would render this hack ineffective.
  - josephg 5y ago
    > So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change. The drive could do things like serve up a malicious version of a system DLL on boot (within the first 20 seconds of being powered on). Then deliver unmodified copies of the file on subsequent read requests. An attack like that would be difficult to detect even if you plugged the drive into another computer. And as for self updating, the payload could make internet requests, and fetch updated versions of itself online. The controller could then look out for any write which contains a well known sequence of (seemingly random) bytes. And then flash itself with subsequent bytes written to disk. The system component just needs to write the update to a temporary file, flush to disk, then immediately deletes it again afterwards. I agree with some other sibling posters that the best protection against this is probably full disk encryption. Is that enabled by default yet on windows or macos?
- aaronmdjones 5y ago
  > And are modern NVMe drives isolated? Is your system secure if you have a malicious PCIe device attached? Only if it's sitting behind an IOMMU. This is rarely the case; although it is starting to improve.
- Fnoord 5y ago
  > Hmm, I’m not sure I agree. Malicious firmware blobs in your disk controller could do all sorts of damage, like silently replacing parts of executable files with whatever they like. Someone made a proof of concept of this a few years ago - where they managed to replace some of the controller firmware in a hard disk. Their modified drive would then silently replace a certain executable with something else. And on that drive, the attack was persistent. See Spritesmods.com [1] for a PoC from 2013 (!!). Guy managed to run Linux on the firmware. [1] http://spritesmods.com/?art=hddhack http://spritesmods.com/?art=hddhack

by jorvi 5y ago

dmos62 5y ago

Could a rogue SSD move things around in your filesystem? If so, couldn't it install a rootkit? Either way, it's not just about backdoors. A blob is like a car that you cannot perform maintenance on. You want to be able to fix bugs, and also inspect it to check if there aren't any. Maybe customize it.

josephg 5y ago

Hmm, I’m not sure I agree. Malicious firmware blobs in your disk controller could do all sorts of damage, like silently replacing parts of executable files with whatever they like. Someone made a proof of concept of this a few years ago - where they managed to replace some of the controller firmware in a hard disk. Their modified drive would then silently replace a certain executable with something else. And on that drive, the attack was persistent. And are modern NVMe drives isolated? Is your system secure if you have a malicious PCIe device attached? (Even if disk controllers are isolated, are graphics cards? Couldn’t my NVMe drive just claim to be a GPU and DMA all it likes?)

3np 5y ago
Full-disk- or file-system-level encryption on everything reduces the impact by a lot.
- flyingfences 5y ago
  How is the full-disk encryption implemented? Not by the disk, I hope.
  - anthk 5y ago
    In OpenBSD, for example, in software.
  - 3np 5y ago
    Naturally. LUKS or ZFS native encryption, for example.
mywittyname 5y ago
This is pretty nifty, but I have to imagine that it is also detectable if you look for it. The drive can't differentiate between being read for execution and being read for analysis. So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change. Such a program could be injected into the firmware of the machine, so it will never be read from disk, and it is unlikely need updating. One could also produce a second, clean room, program which does the same thing. This could serve as a back up in case a buffer overflow or similar exploit is found and leveraged in the first validation program. Additionally, without the ability to self-update its signature database, version updates would render this hack ineffective.
- josephg 5y ago
  > So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change. The drive could do things like serve up a malicious version of a system DLL on boot (within the first 20 seconds of being powered on). Then deliver unmodified copies of the file on subsequent read requests. An attack like that would be difficult to detect even if you plugged the drive into another computer. And as for self updating, the payload could make internet requests, and fetch updated versions of itself online. The controller could then look out for any write which contains a well known sequence of (seemingly random) bytes. And then flash itself with subsequent bytes written to disk. The system component just needs to write the update to a temporary file, flush to disk, then immediately deletes it again afterwards. I agree with some other sibling posters that the best protection against this is probably full disk encryption. Is that enabled by default yet on windows or macos?
aaronmdjones 5y ago
> And are modern NVMe drives isolated? Is your system secure if you have a malicious PCIe device attached? Only if it's sitting behind an IOMMU. This is rarely the case; although it is starting to improve.
Fnoord 5y ago
> Hmm, I’m not sure I agree. Malicious firmware blobs in your disk controller could do all sorts of damage, like silently replacing parts of executable files with whatever they like. Someone made a proof of concept of this a few years ago - where they managed to replace some of the controller firmware in a hard disk. Their modified drive would then silently replace a certain executable with something else. And on that drive, the attack was persistent. See Spritesmods.com [1] for a PoC from 2013 (!!). Guy managed to run Linux on the firmware. [1] http://spritesmods.com/?art=hddhack http://spritesmods.com/?art=hddhack