A hash-based DOS attack on Btrfs [LWN.net]

A hash-based DOS attack on Btrfs

Posted Dec 15, 2012 8:19 UTC (Sat) by eupator (guest, #44581)
In reply to: A hash-based DOS attack on Btrfs by masoncl
Parent article: A hash-based DoS attack on Btrfs

> The broader issue of collisions against crc32c was known when we selected
> the hash. At the end of the day, I think that if someone has write
> permissions to your directory they can prevent creation of arbitrary files.

The problem is far from being limited to such case. Besides the already mentioned unpacking of archives, mirroring remote directories is very common - consider rsync, recursive wget, or version control systems.

(Log in to post comments)

A hash-based DOS attack on Btrfs

Posted Dec 15, 2012 17:49 UTC (Sat) by Karellen (subscriber, #67644) [Link]

Hmmm.....version control systems. That provokes an interesting thought.

Create a Linux patch series, preferably btrfs-related patches for maximum lulz, whose git SHA-1 ids (any blob, tree, or commit ids should be fine) end up generating filenames in the same object-subdirectory with CRC32 collisions, and send a pull request to lkml.

Hilarity ensues!

The object-subdirectory requirement means there's a 40-bit keyspace to search, rather than 32-bit, but one could probably find enough whitespace/punctuation entropy in comments to generate enough collisions to produce at least some effect, even if you can't find enough to lock up a system.

Also, AIUI, pull requests are unconventional and might be ignored, but if you send the patch series directly to the list, the implicit rebasing will destroy the object ids (and therefore the collisions) - unless all the collisions are in file blobs and none of the files have been touched before your patches are applied.

Anyone any idea how plausible/expensive that attack would be?