Malware Could Use SSD Over-Provisioning to Bypass Security Measures
tomshardware.com
tomshardware.com
If we set the OP to smaller than the original value, the controller has to know about it (because the "setting" is telling the controller to use more of the OP). The partition maybe not be expanded, but the controller knows about it.
I have used this OP adjusting in some SSDs to sanitize for nearly a decade. Set OP to near zero, single-pass overwrite accessible area with random data, execute a Enhanced Secure Erase, then set the OP back to original value, execute second ESE. (The second ESE gives a feedback if the OP changing messed the drive up.)
On a malicious firmware, you can make it so the host won't see the content unless it is queried "properly". Or the controller can return malicious content when queried.
Or is the malware executing from non-partitioned disk space?
Basically, whether a program can read the data from the OP area directly doesn't really matter. The privilege needed for that is equal or greater than the privilege needed to resize the OP area anyway.
Shrinking the OP area == making previously inaccessible area accessible.
Link to the paper on which this is based: https://arxiv.org/ftp/arxiv/papers/2112/2112.13923.pdf
It appears as though the attack is based on the assumption that you have admin level access to the computer.
Reading "New Malware Uses", one can't come to any other reasonable conclusion that there exists new malware that, in fact, uses whatever else is in the title.
There's nothing even slightly suggesting that this is speculation. "New Malware Could Use" would be worlds different.
The bleepingcomputer.com title is not misleading because it has the word "can":
"Firmware attack can drop persistent malware in hidden SSD area"
https://www.bleepingcomputer.com/news/security/firmware-atta...
This is a theoretical mechanism for hiding data in the OP areas on SSDs. It cannot be used to compromise anything, because by definition data in the OP area cannot be accessed by the host, and to infect the host you need to infect data it can access. At most it could allow e.g. RAM-resident malware to hide data in the SSD, but there are much easier ways of doing that. If you've compromised the host to the point where you can issue raw commands to compromise the SSD, you can just throw your encrypted data in a file and fake the OS's free space display to hide it. And besides, malware rarely needs copious amounts of local storage anyway. This is a niche technique among niche techniques that some hypothetical highly advanced malware could opt to use for some very specific thing, and my professional opinion as a security researcher is that no malware ever will actually find this technique useful enough to actually use it.
Even the "can drop persistent malware" version is highly misleading, because you need a persistent bootstrap outside the OP area to do anything. You can't just hide your malware in the OP area and expect it to run. That's like hiding a cyanide pill under the couch cushions of your victim and expecting them to find it and swallow it.
Basically, just another case of security academia living in their own little world and coming up with fun but useless ideas. Not relevant to actual malware in the wild; move right along.
A better use case for this technique would be as a data-hiding trick. E.g. you could put stuff in the OP area that you want $government_agency not to find if they seize and scan your device at a border crossing. But then again, there are a million other ways of doing this that don't involve wacko manufacturer-specific SSD nonsense; steganography has been a thing for ages and, if done right, is nigh undetectable. Just put your raw 44.1kHz FLAC music collection on the disk and store whatever encrypted data you want in the LSBs. That's indistinguishable from flat spectrum dither noise.
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.
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.
Ah yes, the famous "it rather involved being on the other side of this airtight hatchway" that raymond chen talks about.
https://devblogs.microsoft.com/oldnewthing/20180227-00/?p=98...
"Recently, researchers have created a technique to vary the over-provisioning area according to the workload in the data storage system..."
So this is building research on research; it doesn't apply to actual SSDs.
"Micron recently released an SSD with a flex capacity feature that changes the capacity of the storage device according to the workload..."
OK, this attack applies to one SSD model that came out recently.
>Recently, many storage devices vary the size of the OP area in real time to optimize performance. [...] The OP area can be freely changed by the user or by the firmware manager.
That said, it might still be a useful technique just for storing data in a hard to detect way.
To make this work, you need to already run on the host the code that extracts the hidden malware and executes it, and at that point you have something that is detectable.