Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Some mention needs to be made of how unreasonably sensationalized the article is.


It 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".


Trust 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.


This is the paper 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.


> They claim to be able to extract the key using hdparm.

No, they claim only to be able to use hdparm to extract the logical block address at which a file is stored. Whether that gives you any useful information is entirely dependent on the internals of the SSD.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: