Slashdot Mirror

← Back to Stories (view on slashdot.org)

Denial-of-Service Attack Found In Btrfs File-System

Posted by timothy on from the at-that-range-a-hammer-works-too dept.

An anonymous reader writes "It's been found that the Btrfs file-system is vulnerable to a Hash-DOS attack, a denial-of-service attack caused by hash collisions within the file-system. Two DOS attack vectors were uncovered by Pascal Junod that he described as causing astonishing and unexpected success. It's hoped that the security vulnerability will be fixed for the next Linux kernel release." The article points out that these exploits require local access.

9 of 210 comments (clear)

  1. Can we get a real Linux filesystem, please? by Anonymous Coward · · Score: 5, Interesting

    btrfs is a step in the right direction, but even now, Linux does not have production-level deduplication (which even Windows has, for crying out loud), encryption, snapshots, or something even close to supplanting LVM2.

    I just got out of a meeting at my job because we are replacing some old large servers... and because Linux has no stable filesystem with enterprise features, looks like things are either going to Windows, or perhaps Solaris x86 (which is expensive.)

    This doesn't mean to suck Sun's teat for ZFS access... but at least try to come close to what even NTFS or even ReFS offers...

    1. Re:Can we get a real Linux filesystem, please? by Anonymous Coward · · Score: 5, Informative

      ZFS on FreeBSD or FreeNAS is great. Easily saturates gigE with a simple mirror of recent 7200rpm disks. It scales up from there, and FreeBSD is pretty rock solid.

    2. Re:Can we get a real Linux filesystem, please? by Tough+Love · · Score: 5, Informative

      NTFS doesn't have snapshots. Instead it relies on volume shadow copies, with known severe performance artifacts caused by needing to move snapshotted data out of the way when new writes come in. Btrfs, like ZFS and Netapp's WAFL, use a far more efficient copy-on-write strategy that avoids the write penalty. The takeaway: I would not go so far as to claim Microsoft has an enterprise-worthy solution either. If you want something with industrial strength dedup, snapshots and fault tolerance, you won't be getting it from Micorosft.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    3. Re:Can we get a real Linux filesystem, please? by maz2331 · · Score: 5, Informative

      ZFS on Linux does exist as a kernel module that is pretty stable and works well. http://zfsonlinux.org/ -- it was put out by Lawrence Livermore National Lab, but can't be included with the kernel distros due to GPL / CDDL license compatability issues.

    4. Re:Can we get a real Linux filesystem, please? by Tough+Love · · Score: 5, Informative

      VSS is the snapshot solution for NTFS, and of course it uses copy-on-write

      Well. Maybe you better sit down in a comfortable chair and think about this a bit. From Microsoft's site: When a change to the original volume occurs, but before it is written to disk, the block about to be modified is read and then written to a “differences area”, which preserves a copy of the data block before it is overwritten with the change.

      Think about what this means. It is not a "copy-on-write", it is a "copy-before-write". Gross abuse of terminology if anybody tries to call it a "copy-on-write", which has the very specific meaning of "don't modify the destination data". Instead, copy it, then modify the copy. OK, are we clear? VSS does not do copy-on-write, it does copy-before-write.

      Now let's think about the implications of that. First, the write needs to be blocked until the copy-before-write completes, otherwise the copied data is not sure to be on stable storage. The copy-before-write needs to read the data from its original position, write it to some save area, then update some metadata to remember which data was saved where. How many disk seeks is that, if it's a spinning disk? If the save area is on the same spinning disk? If it's flash, how much write multiplication is that? When all of that is finally done, the original write can be unblocked and allowed to proceed. In total, how much slower is that than a simple, linear write? If you said "on the order of an order of magnitude" you would be in the ballpark. In face, it can get way worse than that if you are unlucky. In the best imaginable case, your write performance is going to take a hit by a factor of three. Usually, much much worse.

      OK, did we get this straight? As a final exercise, see if you can figure out who was talking nonsense.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
  2. Re:Who ported btrfs to DOS? by macraig · · Score: 5, Funny

    Do I have to choose? Can I hang a medal on him, and then hang him? I'll make the medal 20 pounds to speed up the lynching.

  3. Requires local access by Anonymous Coward · · Score: 5, Funny

    no more dangerous than a fork bomb or filling up /tmp or trying to compile open office.

    1. Re:Requires local access by cryptizard · · Score: 5, Informative

      Sort of, but at least you can recover from those attacks by restarting or booting from an external source to clean up your filesystem. The second attack here leaves you with undeletable files because the file system code responsible for deleting cannot handle the multiple hash collisions. There is no way to recover from that until a patch is pushed out that fixes the problem.

  4. Nice this was found before BTRFS goes stable by Anonymous Coward · · Score: 5, Insightful

    Hopefully more people start fuzzing btrfs so it is that much better when it is declared stable.