3 ms·

I agree that the "attack" as described by the article is nonsense. However, it's only missing a few ingredients necessary to be an actual threat model. When yo

I agree that the "attack" as described by the article is nonsense. However, it's only missing a few ingredients necessary to be an actual threat model. When you're already postulating the abuse of a vendor-specific feature to (somewhat unreliably) hide data, it's not much of a stretch to also hypothesize an attack against the SSD firmware, gaining control over the drive and its numerous ARM cores. This would make it theoretically possible to make the attack much more durable, by incorporating the rootkit into the operation of the SSD itself and protecting its data from being overwritten. For NVMe SSDs that have DMA capability and aren't trapped behind an IOMMU or are given the opportunity to provide an option ROM for the host to run during boot, this could definitely cause trouble for the system as a whole. I suspect there are still a lot of client SSDs out there that lack an effective secure boot protection for their own firmware. Such an attack requires the resources of a state actor, and could only attack a narrow range of systems (those using a particular model of SSD), and requires a separate successful supply-chain attack or other exploit to initially infect the drive. But once infected, SSDs are a pretty good place to hide malicious code and data, because they have plenty of storage, their own processing resources and copious RAM, access to all your data (unless encrypted on the CPU), and is beyond the scope of what antivirus software monitors. And they can potentially interact with the rest of the system, which is why we really need to see IOMMU support taken more seriously. The ability for your NIC and SSD to talk to each other without getting the CPU involved is really cool—when done for the right reasons.

marcan_42 5y ago
Oh, you're absolutely right that modifying SSD firmware gives you a lot of fun possibilities for hijacking a machine, but that is not new either, it's a threat vector that has been known and investigated for many years now. Here's someone running Linux on an HDD controller in 2013: https://spritesmods.com/?art=hddhack&page=1 https://spritesmods.com/?art=hddhack&page=1 It's well known that SSD vendor security is usually atrocious; these companies do not have much experience building secure-boot systems, and there are often vendor-specific backdoor commands and such. You absolutely do not need the resources of a state actor to pull that off; a good reason and 5-6 digits' worth of (competent) security researcher time ought to do it. I've spent half of my life breaking systems that try a lot harder to have secure boot than SSDs, as a hobby. Indeed, IOMMU support is critical in the modern hardware ecosystem. Honestly, any system that does not use them by default for all off-chip peripherals in 2021 is just unsuitable for any kind of sensitive use case. That, plus FDE with hashtree authentication, eliminates SSD compromise as an attack vector.
- wtallis 5y ago
  I certainly didn't mean to imply that hacking the SSD firmware on its own requires state-level resources; rather, covertly rooting the SSD and chaining that into a successful attack on the host system is what adds up to an impressively impractical attack, especially if it's against a target where the host system is sufficiently secured that using the SSD as part of the attack vector is worth the trouble in the first place.

marcan_42 5y ago

Oh, you're absolutely right that modifying SSD firmware gives you a lot of fun possibilities for hijacking a machine, but that is not new either, it's a threat vector that has been known and investigated for many years now. Here's someone running Linux on an HDD controller in 2013: https://spritesmods.com/?art=hddhack&page=1 https://spritesmods.com/?art=hddhack&page=1 It's well known that SSD vendor security is usually atrocious; these companies do not have much experience building secure-boot systems, and there are often vendor-specific backdoor commands and such. You absolutely do not need the resources of a state actor to pull that off; a good reason and 5-6 digits' worth of (competent) security researcher time ought to do it. I've spent half of my life breaking systems that try a lot harder to have secure boot than SSDs, as a hobby. Indeed, IOMMU support is critical in the modern hardware ecosystem. Honestly, any system that does not use them by default for all off-chip peripherals in 2021 is just unsuitable for any kind of sensitive use case. That, plus FDE with hashtree authentication, eliminates SSD compromise as an attack vector.

wtallis 5y ago
I certainly didn't mean to imply that hacking the SSD firmware on its own requires state-level resources; rather, covertly rooting the SSD and chaining that into a successful attack on the host system is what adds up to an impressively impractical attack, especially if it's against a target where the host system is sufficiently secured that using the SSD as part of the attack vector is worth the trouble in the first place.