We should check white-list of allowed filesystems to avoid arbitrary kernel module load when using the -t option for mount(8). We should probably consult something like /proc/filesystems - we definitely do not want the white-list in the udisks sources themselves since that would be a maintenance burden when new filesystems are added to the kernel. Original email follows below. Credit goes to Sebastian Krahmer <krahmer@suse.de> for discovering this. From: Sebastian Krahmer <krahmer@suse.de> To: vendor-sec@lst.de Cc: david@fubar.dk Subject: udisks arbitrary LKM load Hi, via udisks dbus service you can mount arbitrary filesystems inside /media. Since "mount -t $NAME" is called, this also triggers a "modprobe -q -- $NAME" e.g. you can load arbitrary LKMs from /lib/modules for example recently exploitable v4l or whatever just in case your favorite vulnerable LKM is not already in place. Reproducer: dbus-send --system --print-reply --dest=org.freedesktop.UDisks \ /org/freedesktop/UDisks/devices/sr0 \ org.freedesktop.UDisks.Device.FilesystemMount \ string:'$NAME' array:string:'' it requires cd/dvd in sr0 drive and $NAME might be anything for example "nfs4../blah" to load whole nfs stack (appendix string is needed as for just nfs4 mount would re-invoke itself as mount.nfs4). You can also use "proc" to mount proc fs a second time inside /media. There should be some whitelisting in place for allowed FS. Sebastian -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Kay proposed on IM to perhaps use /etc/filesystems so it's under the control of the administrator. For example, if a vulnerability is discovered in the vfat driver the admin can quickly comment out vfat in /etc/filesystem until a new kernel has been deployed.
I'd suggest to simply require admin authentication if a user wants to override the auto detected file system or add non-standard mount options.
(In reply to comment #2) > I'd suggest to simply require admin authentication if a user wants to override > the auto detected file system or add non-standard mount options. Actually, I could imagine some non-UTF8-setups wanting to pass utf8=0,iocharset=ISO8859-5 for e.g. VFAT by default (Of course, it would be even better if these setups were UTF8 but that's another battle...). Anyway, requiring user interaction for a common thing like mounting a filesystem is really annoying for the user (and most passwords dialogs are). In the extreme, it only helps undermine the user's confidence in the OS as a whole and thus makes the system as a whole less secure. We really should try to avoid doing that by default. Checking what we pass to mount(8)'s -t option is not really that hard.
(In reply to comment #3) > (In reply to comment #2) > > I'd suggest to simply require admin authentication if a user wants to override > > the auto detected file system or add non-standard mount options. > > Actually, I could imagine some non-UTF8-setups wanting to pass > utf8=0,iocharset=ISO8859-5 for e.g. VFAT by default (Of course, it would be > even better if these setups were UTF8 but that's another battle...). Those options are whitelisted so a user can specify them without having to authenticate as admin. You can't load arbitrary modules that way AFAICT as modules are prefixed with nls_. > Anyway, requiring user interaction for a common thing like mounting a > filesystem is really annoying for the user (and most passwords dialogs are). I didn't say that mounting hotplugged disks should require authentication in general. Just passing non-standard options. Non-standard in this case means different file system than what auto-detection found. I can't remember ever having to explicitly specify a file system when hal took care of mounting.
Note that CVE-2010-4661 has been assigned to this issue as per http://seclists.org/oss-sec/2011/q1/261 FWIW, I've been busy with other stuff. Will hopefully find some time to work on this next week...
Fixed with this commit: http://cgit.freedesktop.org/udisks/commit/?id=c933a929f07421ec747cebb24d5e620fc2b97037
This patch has introduced an issue, as fuse filesystems do not appear in /proc/filesystems, that would mean maintaining a list of fuse filesystems that are installed on the system. This doesn't sound like something many Operating System vendors would like to be doing. Is there a solution for this?
Please see https://bugs.freedesktop.org/show_bug.cgi?id=36361 (There is just a missing comma in the well_known_filesystems)
Really ! Nobody wants to fix the missing comma at line 5905 in device.c ? It was fixed one week ago in ArchLinux package...
(In reply to comment #7) > This patch has introduced an issue, as fuse filesystems do not appear in > /proc/filesystems, that would mean maintaining a list of fuse filesystems that > are installed on the system. This doesn't sound like something many Operating > System vendors would like to be doing. Is there a solution for this? The filesystems used for block devices are very rarely FUSE filesystems. Please don't reopen this bug; if you need to add concrete fuse filesystems to the udisks whitelist, then open a new bug instead of using this one. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.