Hacker News Reader

Comment by akurms | Hacker News Reader

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.

View on HN

Are you claiming that a random-bit-flipping attack such as targeted read disturb can cause corrupted data to be returned even through data scrambling, a first-level LDPC check and a final CRC check on the output?

From your paper: "We assume that the victim system runs a filesystem on top of MLC NAND flash-based SSD."

It seems very naive to be surprised that people would assume this is an attack on SSDs.

The flash weakness is clearly documented as just being part of their threat model, not part of their research. They say that their contribution is in the filesystem part of the attack, to build on a weakness proposed by a previous flash layer focued paper. So this is completely OK.

If you want to critique the flash paper, or how this paper represents that papers findings, you should turn your attention to:

Yu Cai, Augata Ghose, Yixin Luo, Ken Mai, Onur Mutlu, and Erich Haratsch. “Vulnerabilities in MLC NAND Flash Memory Programming: Experimental Analysis, Exploits, and Mitigation Techniques”. In: 23rd IEEE International Sympo- sium on High Performance Computer Architecture . 2017.

I found a PDF link too: https://pdfs.semanticscholar.org/b9bc/a3c9f531002854af48de12...

I agree the earlier paper shares the same misconceptions.

I don't agree that the authors of the present paper are exempt from criticism for this reason.

Still in the introduction you write:

Based on a recently published paper by Cai et al. [2] that proposes that rowhammer-like attacks are possible on SSDs but does not present an actual attack, we investigate the feasibility of such attacks on SSDs from the system point of view.

So it might be easy for a non-technical reader to jump to that conclusion.

Academics don't write publications in sloppy-journalist-proof ways, though. And that's fine, they have more important audiences they are writing for.

Not sure if you've ever actually been in academia, but on any type of publication (paper, thesis, etc.) it is very well understood that title, abstract, introduction and conclusion are "for the masses" while the rest is for the interested (and assumed-to-be-"qualified") reader.

However, I agree that we should expect science journalists to be in the latter group.

So I see failures in both sides of the communication.

So how would you have written the quoted bit? It seems pretty masses-friendly to me, any addition of disclaimers or weasel words would just detract from it.

To raise an earlier quote, a central sentence from the abstract: "In this paper, we discuss the requirements for a successful, full-system, lo- cal privilege escalation attack on such media, and show a filesystem based attack vector. " This is also a good description for the masses, and only a very sloppy journalist would read past that and jump to premature conclusions.

(side note: I don't think there's any need to get into credentials about who's been in academia. There are lots of terrible writers, and minority opinions about writing, in academia.)

The quote conveys what the author does. That the average journalist assume that it means they have carried out an attack is on their shoulders, because it clearly states they are only looking at it from the filesystem.

That's an entirely unsurprising fact, especially if you've ever played around with cracking/patching. A single-bit change in the right place is sufficient to turn an "are you root/registered/privileged/etc.?" check into its negation. This isn't anything novel or unexpected to anyone who knows how software works.

This is not about having control over the changes (flipping a bit in a file, say), but rather about random corruption.

Also this is not a journal paper, this is a workshop (Usenix "Workshop on Offensive Technologies") which is meant as a kind of get together of academics and practical/industry guys. So just demonstrating an "theoretically obvious" exploit would be fine content for that venue, especially if it's not been academically documented before.

Reply on news.ycombinator.com