Bug 32232 - CVE-2010-4661: Arbitrary kernel module load
CVE-2010-4661: Arbitrary kernel module load
Status: RESOLVED FIXED
Product: udisks
Classification: Unclassified
Component: operations
unspecified
Other All
: medium normal
Assigned To: David Zeuthen (not reading bugmail)
CVE-2010-4661
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-08 07:46 UTC by David Zeuthen (not reading bugmail)
Modified: 2012-03-04 04:59 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Zeuthen (not reading bugmail) 2010-12-08 07:46:46 UTC
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)
Comment 1 David Zeuthen (not reading bugmail) 2010-12-08 07:55:36 UTC
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.
Comment 2 Ludwig Nussel 2010-12-09 01:08:55 UTC
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.
Comment 3 David Zeuthen (not reading bugmail) 2010-12-09 10:10:04 UTC
(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.
Comment 4 Ludwig Nussel 2010-12-20 02:25:58 UTC
(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.
Comment 5 David Zeuthen (not reading bugmail) 2011-03-03 11:24:42 UTC
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...
Comment 6 David Zeuthen (not reading bugmail) 2011-03-15 06:24:11 UTC
Fixed with this commit:

 http://cgit.freedesktop.org/udisks/commit/?id=c933a929f07421ec747cebb24d5e620fc2b97037
Comment 7 soul 2011-05-02 16:30:32 UTC
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?
Comment 8 Benjamin Robin 2011-05-03 12:26:05 UTC
Please see https://bugs.freedesktop.org/show_bug.cgi?id=36361 (There is just a missing comma in the well_known_filesystems)
Comment 9 Benjamin Robin 2011-05-06 01:36:20 UTC
Really ! Nobody wants to fix the missing comma at line 5905 in device.c ?
It was fixed one week ago in ArchLinux package...
Comment 10 David Zeuthen (not reading bugmail) 2012-03-01 13:28:56 UTC
(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.