Hacker News new | past | comments | ask | show | jobs | submit login

Those filesystems also don't trust their input and check bounds correctly. Mounting a malicious ext* partition can trigger code execution so it's never auto mounted and shouldn't be used on removable drives. This is a really weird limitation that the other common file systems don't have



This is true for virtually all filesystems

From the kernel point of view, the filesystem code runs in kernel mode and expects a trusted block device

Some people (from gnome etc) do auto-mount filesystems, which is a crazy idea and they know it but they do not care

https://lwn.net/Articles/951846/


Maybe GNOME is just designed with great anticipation for GNU Hurd :-D


Considering auto mount is now built into systemd I'd say its not such a crazy idea after all


Haha - there are many graybeards who would call most of systemd kinda crazy (myself included). But let's not get derailed into the old systemd debate here :)


Exposing your users to a known (and easily exploited) vulnerability is a sick behavior, regardless of what you think of the authors of said behavior.


Not sure what system you've used, but I've never seen automounting fail to work on ext4 volumes.

That being said, basically every file system ever is vulnerable to the malicious image. Kernel drivers assume that the metadata is sane enough and mistakes are from simple bugs, not deliberate attacks.


I never said it would fail to work, I said it's a massive vulnerability.

And no, implementations of other filesystems like FAT32 and ISO 9660 consider it a security bug when a malicious image gains arbitrarily code execution. What you described is exclusively a Linux desktop problem




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: