Bug 32232 - CVE-2010-4661: Arbitrary kernel module load
Summary: CVE-2010-4661: Arbitrary kernel module load
Status: RESOLVED FIXED
Alias: None
Product: udisks
Classification: Unclassified
Component: operations (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL:
Whiteboard: CVE-2010-4661
Keywords:
Depends on:
Blocks:
 
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.


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.