Modern Linux distros aren't really affected by this. At least in a drive-by sense. Auto-mounting is handled in a safer way than simply telling the kernel to mount the filesystem you just plugged in.

For example, compare the Ubuntu 22.04 behavior (complain that the filesystem is corrupt) vs. Ubuntu 20.04 (panic and reboot). For modern Linux to see the panic, you'd have to manually mount the filesystem (as root/sudo).

ChromeOS, on the other hand, chooses the more YOLO route of auto-mounting via the kernel.

It's funny (and rather cringe-inducing) to us infosec folks, but to 99% of developers they will always say "why would anyone do that?"

The vast majority just truly have no concept that anyone might want to act maliciously. If the engineer themself wouldn't perform a malicious action, they cannot conceive that anyone else would.

I have run into this issue so many times during my career. I now assume that no engineer will ever consider possible malicious actions taken against their code. To the extent that they do consider malicious actions, it will only be things that they themselves would do.

@ekuber @AmbianceAsunder @chort Sure but there are lots of ways of causing that, that are just as unobtrusive, and worse kinds of harm that can be done that require equal access to the physical device — e.g. if you have physical access you can just out and out fry the USB ports with a random normal looking USB.

So with that in mind — how does a kernel panic on a USB damage someone's threat model in a way that none of these other things do?

@alexandria @ekuber @AmbianceAsunder @chort
Copy shops. Though those are probably not running on Linux.

Or those photo copiers that are also scanners and allow the user to save the scan on a USB-Stick.

We'd need to think about ways how a forced reboot can become s.th. more interesting.

@glitzersachen if you have the ability to supply external boot media, but cannot access the power button (kiosk perhaps?)

Another example: Many years ago I found a security "appliance" that allowed passwordless database login by root, with a limited set of privileges. Interestingly, the privileges allowed creating new privileges, but did not allow applying the privileges. However, the new privileges would be applied when the DB restarted. So I combine that with an existing Linux kernel unauthenticated remote DoS that would reboot the machine.

I'm sure people way smarter than me could figure out ways to leverage this.