Will DormannDec 9, 2024

Back when I was poking around with filesystem fuzzing stuff years back, I noticed something odd:

An EXT filesystem can tell the Linux OS how it should behave "if" the filesystem is corrupt, including triggering a kernel panic. In a world where USB thumb drives exist, this seems... not ideal.

Let's see what happens if we plug such a mass storage device into a fully patched Chromebook in 2024...

Oh.

Show threadWill DormannDec 9, 2024

The man page for tune2fs is pretty clear about this capability.

The person who writes the data to the USB mass storage device can specify that both:
1) The OS that reads the device should panic if the filesystem has an error.
2) The filesystem has an error.

🤦‍♂️

Show threadWill Dormann

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.

Dec 10, 2024 at 2:53pmWeb
Show threadJiří EischmannDec 10, 2024
@wdormann Yes, it was patched in udev rules fairly recently. AFAIK in Fedora if the file system is corrupted it gets mounted as read-only and the user gets a message about the problem.
Show threadsanfierroDec 10, 2024
@wdormann How do I replicate this? Preferably in a way such that at first the system mounts the drive thinking it's safe, but then the panic occurs upon trying to list the root directory, for example?
Show threadWill DormannDec 10, 2024

@sanfierro
Whether the kernel crash requires user interaction such as browsing depends on the OS, filesystem, and the type of corruption that has happened. But yeah, when I did the work one of the NTFS corruptions I encountered would panic macOS only when a directory was browsed to, as opposed to at mount time.

I did this about 5 years ago, so aside from me testing this one output on ChromeOS, I haven't really revisited it to see what works against modern OSes.

There's a slide deck about what I did here:
https://insights.sei.cmu.edu/library/death-by-thumb-drive/

Or if you want to hear yours truly walk through it 😂:
https://www.youtube.com/watch?v=8nZlfi578XM

Death by Thumb Drive

In this talk, Will Dormann discusses how to use CERT BFF to fuzz filesystems, and how to analyze kernel-level crashes.

SEI Digital Library
Show threadchristian mockDec 10, 2024
@wdormann I just changed the fstab entry for my /boot partition, as that one's not encrypted and could be used by someone with physical access to send my machine into a boot loop, maybe.
Show threadWill DormannDec 10, 2024
@cm
We'll, they'd need to be on your computer as root to mess with your /boot.
And if an attacker has that level of access, they can do whatever they want. 😀
Show threadchristian mockDec 10, 2024
@wdormann An "evil maid" type attack would suffice, I run encrypted filesystems except for /boot, and this attack might be a denial of service even with secure boot activated. Once you know what's happening it's easily fixed with a linux live CD, but I guess you could confuse the heck out of even seasoned linux admins...
Show threadIndigoAmberDec 11, 2024
@wdormann How does Android deal with this? Could this help with jailbreaking Smart-TVs / media-boxes?
Show threadWill DormannDec 11, 2024
@indigoamber
I don't think that Android supports the EXT filesystem family.
Even if it did, a kernel panic helps nobody here.