A fuzzy issue of responsible disclosure [LWN.net]

A fuzzy issue of responsible disclosure

Posted Aug 12, 2022 22:12 UTC (Fri) by developer122 (guest, #152928)
Parent article: A fuzzy issue of responsible disclosure

Are there any filesystems *intentionally designed* to be resistant to maliciously crafted filesystem images?

The only thing I can think of would be tar or zip files, but even then there are common attacks.

to post comments

A fuzzy issue of responsible disclosure

Posted Aug 13, 2022 7:30 UTC (Sat) by Sesse (subscriber, #53779) [Link] (2 responses)

Neither tar nor zip are deliberately designed with this in mind. Both are from way before the IT industry started worrying much about security.

A fuzzy issue of responsible disclosure

Posted Aug 13, 2022 16:43 UTC (Sat) by developer122 (guest, #152928) [Link] (1 responses)

Thus why I asked. They're a common target so their implementations tend to be security minded, but the filesystems themselves are definitely not.

A fuzzy issue of responsible disclosure

Posted Aug 13, 2022 18:09 UTC (Sat) by Sesse (subscriber, #53779) [Link]

Are you now talking about the formats tar and zip, or the implementations GNU tar and Info-ZIP?

A fuzzy issue of responsible disclosure

Posted Aug 15, 2022 12:09 UTC (Mon) by mcatanzaro (subscriber, #93033) [Link] (6 responses)

Filesystem code has to be resistant to malicious images because people mount filesystems. All the time. Every day. Unless you've filled the USB ports on your computer with glue and removed the network card, you should care about this.

It's OK to fail to mount a corrupted image. It's not OK for the image to start executing code on your computer and eat your lunch. Why would that possibly be considered OK?

Require root privilege to mount a filesystem is cute, but that's not going to stop anyone from mounting filesystems. Users will type their password and mount anyway. Attackers will target whatever supported filesystem is least secure, so it doesn't even matter if one filesystem is in good shape if another supported filesystem is not.

A fuzzy issue of responsible disclosure

Posted Aug 16, 2022 21:15 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

Users will also use FUSE to mount filesystems. At least there the attacker "only" gets local userspace and not root or kernelspace, but https://xkcd.com/1200/

A fuzzy issue of responsible disclosure

Posted Aug 19, 2022 10:58 UTC (Fri) by fratti (subscriber, #105722) [Link] (2 responses)

I completely agree, and don't even understand where filesystem developers are getting this idea from that mounting a filesystem should be an inherently dangerous activity. Imagine if someone told you opening JPEG files in an image viewer resulting in arbitrary code execution was just a fact of life. Hell, it's not like filesystems are the only pieces of code being fed with untrusted binary data that is complex to parse, the entirety of FFmpeg is fuzzed constantly and society is better off for it.

A fuzzy issue of responsible disclosure

Posted Aug 19, 2022 13:53 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

> the entirety of FFmpeg is fuzzed constantly and society is better off for it.

The part of society that gets updates to their FFmpeg are better off at least. (Yes, the solution is to shame the non-updater vendors.)

A fuzzy issue of responsible disclosure

Posted Aug 19, 2022 15:49 UTC (Fri) by flussence (guest, #85566) [Link]

>Yes, the solution is to shame the non-updater vendors.

Everyone who had a hand in the libav mutiny is culpable for half a decade of lost security here, though they'll never be held to account for it.

A fuzzy issue of responsible disclosure

Posted Aug 19, 2022 15:46 UTC (Fri) by flussence (guest, #85566) [Link]

> It's OK to fail to mount a corrupted image. It's not OK for the image to start executing code on your computer and eat your lunch. Why would that possibly be considered OK?

What if it's a well-formed image? Does that make it okay when Windows/GNOME's removable media autoexec anti-feature runs a bunch of code from it?

A fuzzy issue of responsible disclosure

Posted Aug 19, 2022 16:08 UTC (Fri) by hummassa (guest, #307) [Link]

> It's OK to fail to mount a corrupted image. It's not OK for the image to start executing code on your computer and eat your lunch. Why would that possibly be considered OK?

Regardless of if anyone think "it's OK" or not, the *fact* is that executing kernel code to decode any foreign file opens an attack surface. So, yes, the relevant code paths should be hardened, its reach diminished, etc.

A fuzzy issue of responsible disclosure

Posted Aug 16, 2022 15:12 UTC (Tue) by sandeen (guest, #42852) [Link]

Absolutely. Modern XFS, for example, has checksums on every piece of metadata, and has metadata verifiers to functionally validate every bit of metadata read from and written to disk. So the current version of the XFS on-disk structure is fairly resistant to casual fuzzing. But then fuzzing adapts, and begins to write invalid metadata with a valid checksum, and the arms race continues (as it should, I suppose.)