5 ms·

The full paper is here: https://www.usenix.org/system/files/conference/woot17/woot17-paper-kurmus.pdf https://www.usenix.org/system/files/conference/woot17/woot

The 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 ago
If 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.
- wtallis 9y ago
  > 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. Except that the NAND flash that's vulnerable to these attacks is being phased out of production as quickly as the fabs can be converted. Coming up with more plausible ways to obtain the oracular knowledge necessary to properly target this attack is of no use if the underlying storage medium no longer has the failure mechanism that's being exploited.
- ericseppanen 9y ago
  I don't think we can assume that all impractical attacks will eventually become feasable. There are some things that are not just hard, but computationally infeasable. Triggering random bit errors and expecting to pass both the LDPC error correction as well as the extra checksum probably falls in this category. I'm afraid I don't follow your suggestion that triggering SSD GC could somehow result in some other attack. This is simply the firmware automatically repairing the damage you were attempting to inflict. I don't see an additional attack vector here. Since flash is already an unreliable media, hardware & firmware already works very hard to conceal and silently repair any errors before they accumulate to a data corruption scenario. This is very different from a rowhammer-type attack because there is an active CPU that already works to prevent this type of damage when it occurs naturally (or due to a naive workload that reads hot locations often).
  - bostik 9y ago
    > I'm afraid I don't follow your suggestion that triggering SSD GC could somehow result in some other attack. I was thinking more of the wear-leveling of the NAND cells. (Sibling comment from wtallis points out that the entire technology is being phased out so that's pretty much covered then.) What I had in mind was a write-spray to identifiable locations. Wear-leveling cycles cells out from active to inactive, and from inactive back to active. If you could prepare a whole bunch of cells with suitable patterns, AND had a way to get occasional cells cycled in uninitialised - then having predictable control over "where"[ß] a cell is cycled back in could allow to target the reads and writes to perform the attack. We don't need control over which cells are cycled in if majority of incoming cells already have our data on them from their previous active incarnation. ß: There is indirection above the physical cells and their addressing. I just don't know how many layers.
akurms 9y ago
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.
- jontro 9y ago
  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.
  - fulafel 9y ago
    Academics don't write publications in sloppy-journalist-proof ways, though. And that's fine, they have more important audiences they are writing for.
    - vog 9y ago
      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.
      - deleted 9y ago
        [deleted]
      - fulafel 9y ago
RachelF 9y ago
And another thing, you have little or no access to the physical layout of the SSD - you are writing through a complex algorithm that does wear levelling, block remapping and lazy deletions. To write to NAND flash, you need to erase the entire block first. Perhaps you could corrupt the DRAM cache of the SSD, though?
baruch 9y ago
It should be noted that while the disks do keep counters their space for such counters is small and you can sometimes over it and do some places are forgotten. I've seen it happen on HDDs and had this as a root cause of some repeated failures at some customers due to their specific workloads and their interaction with the system. I do support you in the general point that this is rather unit to work on SSDs but it may work on HDDs as they have a similar failure mode and physical locality is easier to achieve there on them. That said they unlikelihood didn't make it impossible. Filesystems should be written and tested against such attacks.

bostik 9y ago

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

wtallis 9y ago
> 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. Except that the NAND flash that's vulnerable to these attacks is being phased out of production as quickly as the fabs can be converted. Coming up with more plausible ways to obtain the oracular knowledge necessary to properly target this attack is of no use if the underlying storage medium no longer has the failure mechanism that's being exploited.
ericseppanen 9y ago
I don't think we can assume that all impractical attacks will eventually become feasable. There are some things that are not just hard, but computationally infeasable. Triggering random bit errors and expecting to pass both the LDPC error correction as well as the extra checksum probably falls in this category. I'm afraid I don't follow your suggestion that triggering SSD GC could somehow result in some other attack. This is simply the firmware automatically repairing the damage you were attempting to inflict. I don't see an additional attack vector here. Since flash is already an unreliable media, hardware & firmware already works very hard to conceal and silently repair any errors before they accumulate to a data corruption scenario. This is very different from a rowhammer-type attack because there is an active CPU that already works to prevent this type of damage when it occurs naturally (or due to a naive workload that reads hot locations often).
- bostik 9y ago
  > I'm afraid I don't follow your suggestion that triggering SSD GC could somehow result in some other attack. I was thinking more of the wear-leveling of the NAND cells. (Sibling comment from wtallis points out that the entire technology is being phased out so that's pretty much covered then.) What I had in mind was a write-spray to identifiable locations. Wear-leveling cycles cells out from active to inactive, and from inactive back to active. If you could prepare a whole bunch of cells with suitable patterns, AND had a way to get occasional cells cycled in uninitialised - then having predictable control over "where"[ß] a cell is cycled back in could allow to target the reads and writes to perform the attack. We don't need control over which cells are cycled in if majority of incoming cells already have our data on them from their previous active incarnation. ß: There is indirection above the physical cells and their addressing. I just don't know how many layers.

akurms 9y ago

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.

jontro 9y ago
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.
- fulafel 9y ago
  Academics don't write publications in sloppy-journalist-proof ways, though. And that's fine, they have more important audiences they are writing for.
  - vog 9y ago
    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.
    - deleted 9y ago
      [deleted]
    - fulafel 9y ago

RachelF 9y ago

And another thing, you have little or no access to the physical layout of the SSD - you are writing through a complex algorithm that does wear levelling, block remapping and lazy deletions. To write to NAND flash, you need to erase the entire block first. Perhaps you could corrupt the DRAM cache of the SSD, though?

baruch 9y ago

It should be noted that while the disks do keep counters their space for such counters is small and you can sometimes over it and do some places are forgotten. I've seen it happen on HDDs and had this as a root cause of some repeated failures at some customers due to their specific workloads and their interaction with the system. I do support you in the general point that this is rather unit to work on SSDs but it may work on HDDs as they have a similar failure mode and physical locality is easier to achieve there on them. That said they unlikelihood didn't make it impossible. Filesystems should be written and tested against such attacks.