10 ms·
Rowhammer-like attack on SSDs can provide root privileges to attacker
- X-Istence 9y agoGoogle cache as it seems to be offline for me: http://webcache.googleusercontent.com/search?q=cache:LREtpAAixkMJ:www.myce.com/news/ibm-researchers-rowhammer-like-attack-ssds-can-provide-root-privileges-attacker-82386/+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:LREtpAA...
- dmitrygr 9y agoThis is idiocy. Modern drives AES encrypt data to provide whitening. You do not have the key nor do you set it or care for it. Without it you'll not be able to pull this off. Their attack will only work on very old SSDs that do not whiten data. All modern MLC/TLC chips REQUIRE whitening and AES is often used since it whitens well and is fast.
- dom0 9y agoNot necessarily. Depending on the mode bitflips produce predictable results and a SSD probably does not authenticate blocks.
- dmitrygr 9y agoAES is not linear thanks to the SubBytes step. You don't know the key. Good luck :)
- dom0 9y agoAES being linear or not is wholly irrelevant for this. I recommend you read this article: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
- dmitrygr 9y agoPlease explain how you'll mutate a single bit of output given only input and no knowledge of key
- snakeanus 9y agoIf you use a mode like CTR you just flip the corresponding ciphertext bit. As for CBC there are padding-oracle attacks.
- tedunangst 9y agoDo SSDs use CTR mode? How does one perform a padding oracle against an SSD? I feel like we're pretty far away from the relevant context, which is users corrupting data on an SSD.
- heheocoenev 9y agoXTS mode for block storage. Can't be CBC or CTR, where would you Store the IV or counter/nonce?
- Scaevolus 9y agoYou could store it in the block metadata, which SSD flash translation layers already use for wear-leveling purposes.
- tedunangst 9y agoThis sounds more like random speculation than informed commentary.
- rlanday 9y agoDoes the SSD let you read the raw ciphertext to perform that attack? Or does it only expose the decrypted data?
- 9y ago
- burkaman 9y agoThis would be a much more productive comment if you took out the first sentence.
- wtallis 9y agoSome mention needs to be made of how unreasonably sensationalized the article is.
- burkaman 9y agoIt doesn't seem sensationalized to me, but I don't know much about the domain. Other ways to phrase a comment are "This isn't very dangerous in practice" or "This won't work on modern hardware" or "The risk in this article is exaggerated".
- wtallis 9y agoTrust me, it's sensationalized to the point of being highly irresponsible reporting. This research first made the rounds early this year, and I analyzed it in depth. Properly explaining all the caveats behind this "attack" requires more space than this entire article. Among other things, making a successful attack would require sufficient privilege level to bypass all layers of read caches (and probably also all write caches), a target SSD that doesn't use modern 3D NAND, and intimate knowledge of the internals of the SSD controller and firmware, potentially up to the internal state of the LFSR or AES used to scramble data before it is written to the flash. There's interesting stuff in this research; it highlights aspects of the unreliability of flash memory that I haven't previously seen emphasized so clearly. But since everything about SSD design already assumes that the flash memory is thoroughly unreliable and untrustworthy, these corner cases don't rise to the level of a real-world vulnerability.
- jontro 9y agoThis is the paper https://pdfs.semanticscholar.org/b9bc/a3c9f531002854af48de121cdcc8e0520c7f.pdf https://pdfs.semanticscholar.org/b9bc/a3c9f531002854af48de12... that this is based on. They claim to be able to extract the key using hdparm. Afaik that needs elevated permissions to run.
- street 9y agoDoes flipping a bit in the ciphertext not flip the same bit in the plain text, for naive implementations?
- dmitrygr 9y agoNo because of SubBytes step
- czinck 9y agoAES and similar algorithms are specifically designed to not do that, because otherwise details of the ciphertext leak details about the plaintext. https://en.wikipedia.org/wiki/Differential_cryptanalysis https://en.wikipedia.org/wiki/Differential_cryptanalysis is about exploiting any unintentional leak of info like that.
- rocqua 9y agoAES in CTR mode does work like that. So do most stream ciphers. Differential cryptanalysis is not about defending against bit-flips. Instead, it is about comparing two cipher texts to learn something about the relation between corresponding plain-text. This is only possible on AES-CTR if you have to ciphertexts with the same key and nonce/IV. This is why a nonce is supposed to be used only once. Same goes for other xor based stream ciphers.
- the8472 9y agoNot all cipher modes are immalleable.
- dmitrygr 9y agoAES without a known key doesn't allow modifications of a single output bit by only modifying plaintext and having no way to observe cyphertext.
- tedunangst 9y agoAnd which cipher modes are used by SSDs?
- dom0 9y agoLooking at this thread of comments a couple hours later, clearly, no one has an idea (so any security cleams seem unbased).
- dijit 9y agoYou're right. The AES key used on _all_ drives is 8bytes. 00000000 If it's anything else the user would have to enter the key. So in practice, it's not /really/ encrypted.
- Piskvorrr 9y agoNope. The drive's firmware generates the key pseudorandomly when it receives the "securely wipe drive" command, this happens at least once before the drive is shipped from a factory. Thence, the key remains unchanged, unless another "securely wipe drive" command is received. This happens transparently to the user.
- leereeves 9y agoEvery SSD works that way? Is that a standard?
- Piskvorrr 9y agoBog-standard. As mentioned in sibling thread, you could find really old SSDs without this feature, but they're getting rare.
- ericseppanen 9y agoDrives that lack cryptographic scrambling are not rare. Search a few vendors' sites and you'll find some that don't support "self-encrypting" capabilities.
- wtallis 9y agoIt's pretty common for drives to have hardware AES support even if they don't implement the full TCG Opal feature set for use as a "self encrypting drive". I think Phison is the only SSD controller vendor that doesn't advertise encryption capability on all of their mainstream SSD controllers.
- 9y ago
- ericseppanen 9y agoGood modern SSDs do this. Cheap SSDs use only a non-cryptographic scrambler.
- pkaye 9y agoI couldn't get access to the video. How do they work around the error correction and wear leveling algorithms?
- alternateben 9y agoThey don't. I was at the presentation. It assumes that the target FS is ext3 and one has bypassed the mitigations you mention and any others that get in the way. Mention is made of previous generation SSD tech that was vulnerable to charge leakage during IO to adjacent cells.
- rhizome 9y agoAssuming a spherical SSD...
- wmf 9y agoMods, please change URL to original source: https://www.usenix.org/conference/woot17/workshop-program/presentation/kurmus https://www.usenix.org/conference/woot17/workshop-program/pr...
- groupmonoid 9y agoThis really needs to be done. The journalist's article has nothing to do with the paper (I do not think the journalist read the paper)
- heisenbit 9y agoThey may have read but they clearly did not understand. Looks like they realized it now: > Update: Our reporting was incorrect, here is a comment from the author of the report: “Author here, I would like to set the record straight.We do not claim to have an attack on SSDs. The journalist seems to have misunderstood and not read the paper. The attack demonstrated is not on an FPGA or SSD. The main point this paper makes and demonstrates is that if you can cause corruption of a full block (i.e., completely garble contents of a chosen block), then you can elevate privileges (with some assumptions, like using ext3). Note that this result does not depend on whether you are using an SSD, a disk, or any other storage for your filesystem.”
- ericseppanen 9y agoThe full paper is here: https://www.usenix.org/system/files/conference/woot17/woot17-paper-kurmus.pdf https://www.usenix.org/system/files/conference/woot17/woot17... I am unconvinced. They have not demonstrated an attack on any real-world SSD; instead they have attacked their own FPGA-based design. The attack assumes that you can control or predict the physical location of data on an SSD, which is unlikely on a system that is doing other I/O. But worst of all, the "attack" assumes that if you can target the right physical block/pages in flash, you can somehow hit that location with sufficient read-disturb that the result will decode successfully, AND pass ECC checks, meaning the resulting bad data will be returned to the host system. I am highly skeptical that this could ever work on a real SSD. The combination of BCH/LDPC error-correction codes combined with a final checksum should make "random bit flipping" impossible to leverage. Oh, and there's one more thing: SSD firmware keeps counters, to ensure that read disturb can't corrupt data. Any read pattern that hammers a particular location will trigger garbage collection or data rewrite to a fresh location.
- bostik 9y agoIf there's anything we've seen, over and over again, it's that theoretical and infeasible attacks eventually become, in order: 1) possible 2) feasible; and 3) reliable to the point of weaponization It may take 5 years. It may take 20 years. It will invariably require a huge amount of other research, only some of which will appear relevant. Then all of a sudden the intermediate pieces are all understood and the first practical attack becomes possible. Even if this attack only works against an ideal target, it still shows a new way of thinking about particular attacks. > Any read pattern that hammers a particular location will trigger garbage collection or data rewrite to a fresh location. I can't help thinking that you may have inadvertantly outlined how an eventual practical attack will be performed. This wouldn't be the first time a mitigation method is abused to prepare an attack either - what if you had statistical methods at your disposal to predict how the SSD's wear-leveling redirects your writes? Could you arrange for the cells to be rotated in and out in a reliably determinable pattern? I'm not discounting your doubts, btw. I'm just pointing out that dismissing the attack due to its current sophistication (or lack thereof) feels shortsighted.
- 9y ago
- Teknoman117 9y agoIf such an attack were able to reliably set data in a flash device, could this be defeated by whole disk encryption and block checksums? Whole disk encryption would be to counter the ability to set precise values (checksums would be no use if you could just set a correct one in your attack) and then checksums to detect, well, data corruption?