| |||||||||||||
A hash-based DOS attack on BtrfsA hash-based DOS attack on BtrfsPosted Dec 13, 2012 17:33 UTC (Thu) by cyanit (guest, #86671)Parent article: A hash-based DoS attack on Btrfs
It's not local if you have a web server storing files with partially user selected names.
(Log in to post comments)
A hash-based DOS attack on Btrfs Posted Dec 13, 2012 20:00 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
It seems like it's a little stronger constraint than "partially user selected". The users need enough knowledge of one part of the filename plus the ability to influence the other part to force the hash. Certainly anybody who hasn't specifically thought about this risk (and why would they?) should re-evaluate either their file naming or their use of btrfs.
Today's web browsers seem to prefer to give e.g. PDFs downloaded for viewing the filename chosen by the provider unless it is taken. That ought to allow you to wreck a vulnerable btrfs filesystem by giving carefully chosen names to a series of apparently interesting PDFs.
A hash-based DOS attack on Btrfs Posted Dec 14, 2012 17:29 UTC (Fri) by dakas (guest, #88146) [Link] It seems like it's a little stronger constraint than "partially user selected". The users need enough knowledge of one part of the filename plus the ability to influence the other part to force the hash.Sure? If several last parts of the filename have the same length and CRC and are combined with the same first part of the filename (even if this first part is unknown), why would the resulting CRC not clash? We are not talking about cryptographic hashes here.
A hash-based DOS attack on Btrfs Posted Dec 17, 2012 13:15 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
"The name consists of a constant prefix plus my user-selected suffix" would constitute enough information. I was thinking more of cases where the prefix /varies/, e.g. because it's used for content addressing, or to serial number the files, or whatever other scheme is in use.
Most code I've worked on that downloaded arbitrary files and gave them names based on their origin (and thus which could be vulnerable to this attack) prefixed the filenames with some varying code or number such as a node identifier. So a naive "assume constant prefix" wouldn't hurt us, but if you could guess our naming scheme (and if we used btrfs) there's definitely a window.
A hash-based DOS attack on Btrfs Posted Dec 14, 2012 7:23 UTC (Fri) by eduperez (guest, #11232) [Link]
Is it that common for web applications to store user-supplied files using user-supplied names?
As a web developer, that situation has always seemed very scary to me: too many "what if" conditions that I could miss and leave the server open for attacks. I prefer to store such files using application-generated names, and (if needed) store the user-supplied name in a database.
A hash-based DOS attack on Btrfs Posted Dec 14, 2012 10:22 UTC (Fri) by robert_s (subscriber, #42402) [Link]
People seem to be overlooking zipfiles/tarballs.
It wouldn't be particularly difficult to trick a user into unpacking an archive that had 500 crazily named files - all of a sudden, they're there on their filesystem.
And I'm sure there are plenty of web services that accept zips of multiple files to save a user having to upload them all individually. Some may unpack them all in-memory, only saving out recognized files somewhere else (probably with a different filename). But I'm sure many unpack them ("blindly") in a temporary directory and deal with them from there.
A hash-based DOS attack on Btrfs Posted Dec 15, 2012 1:00 UTC (Sat) by naptastic (subscriber, #60139) [Link]
Let's say a malicious user uploads a bunch of these files through a compromised Wordpress or Joomla site. I realize this is a bit of a stretch, given how secure these platforms have historically been, but bear with me. If these files contain code that hackers can use to do... whatever it is they do... wouldn't this make it very difficult to clean the account?
A hash-based DOS attack on Btrfs Posted Dec 14, 2012 10:23 UTC (Fri) by Wol (guest, #4433) [Link]
It can be a royal nuisance if they don't ...
Photo printers now typically print the filename on the back of the print. If I take a CD in and print from the in-store machine, it has my filename on the back. If I upload them, and get them by Royal Mail or go and collect, it has some random name on the back - and how do I *easily* track down the file it was printed from?
Cheers,
A hash-based DOS attack on Btrfs Posted Dec 14, 2012 11:03 UTC (Fri) by hummassa (subscriber, #307) [Link]
That's a non sequitur. Nothing prevents them from storing the original filename along with the photo (but not the photo under the original filename), and from printing the original filename (as opposed to the filename under which the photo is stored in their storage system) in the back of the physical print.
A hash-based DOS attack on Btrfs Posted Dec 20, 2012 3:53 UTC (Thu) by cibyr (subscriber, #87609) [Link]
If only my operating system had some sort of system for storing the contents of files with their names, then I wouldn't have to keep track of that stuff in a database...
Oh wait, we do have that! It's called a file system! I assume it can efficiently handle arbitrary combinations of file contents and names.
|
|||||||||||||