A fuzzy issue of responsible disclosure [LWN.net]

A fuzzy issue of responsible disclosure

Posted Aug 15, 2022 12:09 UTC (Mon) by mcatanzaro (subscriber, #93033)
In reply to: A fuzzy issue of responsible disclosure by developer122
Parent article: A fuzzy issue of responsible disclosure

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