Thursday, May 25th 2017
Attacks Discovered that can Corrupt MLC-based SSD Data
It appears that although MLC NAND-based SSDs have many advantages to HDD's from a physical-reliability point of view, the old spinning rust drives might still have one advantage over SSDs: A specially crafted write operation can't corrupt your data.
That's what a new report from Carnegie Mellon University, Seagate, and ETH Zürich is showing: That MLC-based SSD Drives are vulnerable to data-corrupting attacks as simple as a specially crafted write operation.
The first attack is compared to a "row hammer" attack, in which thrashing the drive with read or write operations along the border of a cell can corrupt legitimate data in nearby cells. Most attacks operate in variations of this principle, but some also rely on techniques such as special sequences of operations that will cause cached data and pages to be lost, effectively ruining your precious file the SSD was waiting to write to its media.
HDDs for their part, are not completely data safe even when they are operating correctly. They have a UBER (unrecoverable bit error rate) rating that indicates how often the HDD will make a (mostly random) mistake reading its data from the platter. This phenomenon (often referred to as "bit-rot") is not common in a correctly functioning HDD, but it does happen. The difference is it's not directly triggerable by a specially crafted write: Bit-rot errors are more or less random. Needless to say, the potential for malware to utilize this trigger-able corruption on your SSD is not a good thought at all.
If you want the technical details, they are available in the source link. For now, all you need to know is pretty much all SSDs are vulnerable to what was discovered here, but no exploits are live yet and due to there being no money in just wrecking your stuff (as opposed to say, ransoming it), there probably won't be a significant amount of malware featuring this exploit. Just practice good data hygiene as per usual and chances are all will be well. We don't mean to chase you back to HDD land just yet.
Oh, and one final caveat: SLC SSDs are immune, but good luck finding one that isn't outrageously expensive.
Source:
bleepingcomputer
That's what a new report from Carnegie Mellon University, Seagate, and ETH Zürich is showing: That MLC-based SSD Drives are vulnerable to data-corrupting attacks as simple as a specially crafted write operation.
HDDs for their part, are not completely data safe even when they are operating correctly. They have a UBER (unrecoverable bit error rate) rating that indicates how often the HDD will make a (mostly random) mistake reading its data from the platter. This phenomenon (often referred to as "bit-rot") is not common in a correctly functioning HDD, but it does happen. The difference is it's not directly triggerable by a specially crafted write: Bit-rot errors are more or less random. Needless to say, the potential for malware to utilize this trigger-able corruption on your SSD is not a good thought at all.
If you want the technical details, they are available in the source link. For now, all you need to know is pretty much all SSDs are vulnerable to what was discovered here, but no exploits are live yet and due to there being no money in just wrecking your stuff (as opposed to say, ransoming it), there probably won't be a significant amount of malware featuring this exploit. Just practice good data hygiene as per usual and chances are all will be well. We don't mean to chase you back to HDD land just yet.
Oh, and one final caveat: SLC SSDs are immune, but good luck finding one that isn't outrageously expensive.
10 Comments on Attacks Discovered that can Corrupt MLC-based SSD Data
spritesmods.com/?art=hddhack
bit of light reading.
EDIT: Ah, I see what I did. I'm saying that's an advantage HDDs hold over SSDs, but honestly it could have been worded more clearly. The article Solaris linked while interesting, maintains that status quo.
First, you need to create code that can directly access the SSD controller as most OS's disallow such access by default. Second, you need the code for interfacing with the SSD controller of target, not easy as there are literally 1000's of different controllers out there. Third, you would need to write your code for the host OS[generally]. Fourth, you need to engineer an injection method to the host system. Any code that matches these characteristics is going to be flagged by any competent AntiMalware/AntiVirus. This would be near impossible to pull off unless you had direct physical access to the system you want to affect.
Seeing this line separately completely threw my brain off balance.
If somebody is terrified then winning the lottery comes with same odds as this ^ one.