Slashdot Mirror
SSD Drives Vulnerable To Rowhammer-Like Attacks That Corrupt User Data (bleepingcomputer.com)
An anonymous reader writes: NAND flash memory chips, the building blocks of solid-state drives (SSDs), include what could be called "programming vulnerabilities" that can be exploited to alter stored data or shorten the SSD's lifespan. According to research published earlier this year, the programming logic powering of MLC NAND flash memory chips (the tech used for the latest generation of SSDs), is vulnerable to at least two types of attacks.
The first is called "program interference," and takes place when an attacker manages to write data with a certain pattern to a target's SSD. Writing this data repeatedly and at high speeds causes errors in the SSD, which then corrupts data stored on nearby cells. This attack is similar to the infamous Rowhammer attack on RAM chips.
The second attack is called "read disturb" and in this scenario, an attacker's exploit code causes the SSD to perform a large number of read operations in a very short time, which causes a phenomenon of "read disturb errors," that alters the SSD ability to read data from nearby cells, even long after the attack stops.
The first is called "program interference," and takes place when an attacker manages to write data with a certain pattern to a target's SSD. Writing this data repeatedly and at high speeds causes errors in the SSD, which then corrupts data stored on nearby cells. This attack is similar to the infamous Rowhammer attack on RAM chips.
The second attack is called "read disturb" and in this scenario, an attacker's exploit code causes the SSD to perform a large number of read operations in a very short time, which causes a phenomenon of "read disturb errors," that alters the SSD ability to read data from nearby cells, even long after the attack stops.
Because, you jackass, the discovery of flaws is what allows continuous improvements to be made. I mean, let's NOT find ways to make cars safer by readily exploring all opportunities to keep children safe in the event of a car crash. Let's NOT fund avionics to improve QOL where air flight is concerned. Let's NOT safeguard data to keep sensitive information that our enemies can use to dismantle our way of life our of their hands.
Why don't you tell us what you do that's "useful" on a day-to-day basis. And make it a good one, because it's gotta be something that benefits society as a whole.
What with you being so elite and all.
...I don't think it has much real-world worry. If you're running an intentionally malicious program on your computer, you've got far worse problems. A SSD is one device. A single credit card number is worth thousands of dollars to you and possibly dozens of hours of your valuable time to fix.
I do wonder, is there such an equivalent vulnerability in platter drives? Writing rapidly to the inside and outside of the platter so the heads scream back and forth over and over? (Kind of like the bad old days of exceeding your RAM and thrashing everything to a page file as your heads go CLICK CLICK CLICK CLICK.)
Come to think of it, I wonder if you could VARY the read/write speed of a hard drive by changing your write patterns. So if you can get the heads to swing at a certain frequency, you could start a resonant oscillation of the heads which, if tuned right, would cause a complete mechanical failure.
We used to do that ON PURPOSE. It's wasn't mechanical failure, it was an undocumented feature. http://www.catb.org/~esr/jargo...
...I don't think it has much real-world worry. If you're running an intentionally malicious program on your computer, you've got far worse problems. A SSD is one device. A single credit card number is worth thousands of dollars to you and possibly dozens of hours of your valuable time to fix.
Assuming you got access to anything valuable with the process you're running as. The point of rowhammer was that you could flip bits in other processes, Imagine for example if you have found an exploit in the web server but all it has access to is public files but you could flip the permission bits on /etc/passwd to be world readable that would be a pretty big exploit. If you can use a "harmless" service running as a non-privileged user to create a denial-of-service attack, that surely has some value too.
Live today, because you never know what tomorrow brings
I don't think that has a realistic chance of working -- filesystems tend to write file contents in difficult to predict geographical locations.
I think what would be more realistic is using this as a hypervisor escape.
Even then, I'm curious how this attack is supposed to work now that most SSDs use wear leveling.
In other news SSDs are susceptible to actual hammers as well, no work around has been found.
There is no real world practical worry for this.
This hack relies on the ability to rewrite specific pages in NAND flash. In fact, the attack is well known in NAND flash - read and write disturbs are documented issues with NAND flash since the beginning. Every NAND flash datasheet mentions how you can and cannot program it in order to minimize the probability of disturbs. It's why NAND flash has the "spare area" - because even following the recommendations (always program from page 0 through consecutive pages, never skip around and always program full pages at a time) you will encounter a disturb event eventually.
Now, this requires raw NAND access. But practically all flash memory your PC uses is managed. The SSD has a controller on it sitting between the SATA or PCIe bus and the raw NAND flash. Even memory cards are managed - CompactFlash, SD/MMC, Memory Stick are managed. Only the xD and SmartMedia actually are raw NAND (the controller is in the interface) formatted in special ways.
And managed memory means you can't access the raw media because the management controller is doing its very best to mitigate flash memory drawbacks (like limited program-erase cycles) and problems (like read/write disturbs) by using such fancy technology as wear-levelling. This way even if you write to the same sector always, it's actually walking around the physical media so no part of the actual flash chip is getting more worn out than the others.
And modern SSDs have so much state in them that knowing where your write actually goes in the physical storage array is impossible to know - you need to know the exact state of the array including the states of all the pages (good data, dirty data, ready to be erased, etc). because when it comes time to garbage collect and all that, all the previous state is important as it influences the new state. (And all this contributes to write amplification - where writing N bytes actually causes N+M bytes to be written because of flash management).
I'm not impressed with the findings, since I read all about them in a Toshiba (inventor of NAND flash) application note over a decade ago. It's exactly what Toshiba said would happen and why you need to follow the rules (which every managed controller does).
To be more impressed, they need to demonstrate the results using every day SSDs instead of special test and development boards that let them abuse the raw NAND.
...I don't think it has much real-world worry. If you're running an intentionally malicious program on your computer, you've got far worse problems. A SSD is one device. A single credit card number is worth thousands of dollars to you and possibly dozens of hours of your valuable time to fix.
What if you're running a virtual instance on a cloud platform, and somebody else is running another virtual instance on the same platform, sharing the same physical memory and SSD ?
Storage access is mediated on so many levels that even vendors have a hard time identifying whether even relatively simple performance problems are the result of an application, the application subsystem (databases), the operating system, the network system, the storage system, the storage fabric or the computer system.
I don't see how it would ever be possible to exploit this, especially when the flash vendors are aware of it and the closest software levels of the hardware are deliberately written in ways to inhibit it.