Macos xnu missing locking in checkdirs_callback() enables race with fchdir_common() Vulnerability / Exploit
/
/
/
Exploits / Vulnerability Discovered : 2019-11-05 |
Type : dos |
Platform : macos
[+] Code ...
On macOS, when a new mount point is created, the kernel uses checkdirs() to, as
a comment above the function explains: "Scan all active processes to see if any
of them have a current or root directory onto which the new filesystem has just
been mounted. If so, replace them with the new mount point."
In other words, XNU behaves as follows:
$ hdiutil attach ./mount_cwd.img -nomount
/dev/disk2
$ cd mnt
$ ls -l
total 0
-rw-r--r-- 1 projectzero staff 0 Aug 6 18:05 underlying
$ mount -t msdos -o nobrowse /dev/disk2 .
$ ls -l
total 0
-rwxrwxrwx 1 projectzero staff 0 Aug 6 18:04 onfat
$
(This is different from e.g. Linux, where the cwd would still point to the
directory on the root filesystem that is now covered by the mountpoint, and the
second "ls -l" would show the same output as the first one.)
checkdirs() uses proc_iterate() to execute checkdirs_callback() on each running
process. checkdirs_callback() is implemented as follows:
/*
* XXX Also needs to iterate each thread in the process to see if it
* XXX is using a per-thread current working directory, and, if so,
* XXX update that as well.
*/
`p->p_fd` contains the current working directory (`->fd_cdir`) and
root directory (`->fd_rdir`) of the process; it is protected against
modification by proc_fdlock()/proc_fdunlock(). Because checkdirs_callback()
does not hold that lock across the entire operation, several races are possible;
for example:
- If `fdp->fd_cdir == olddp` is true and `fdp->fd_cdir` changes between the
read `tvp = fdp->fd_cdir;` and the second `proc_fdlock(p);`,
`vnode_rele(tvp);` will release a nonexistent reference, leading to reference
count underflow.
- If `fdp->fd_cdir == olddp` is true and the process calls chroot() between the
first locked region and the second locked region, a dangling pointer will be
written back to `fdp->fd_rdir`.
I have written a simple reproducer for the first scenario; however, since the
race window is quite narrow, it uses dtrace to make the race easier to hit (so
you have to turn off SIP).
In one terminal, launch the dtrace script as root:
======================================================
Projects-Mac-mini:mount_cwd projectzero$ sudo ./test.dtrace
dtrace: script './test.dtrace' matched 10 probes
dtrace: allowing destructive actions
======================================================
In a second terminal, set up the loop device and launch the ./flipflop2 helper:
======================================================
Projects-Mac-mini:mount_cwd projectzero$ hdiutil attach ./mount_cwd.img -nomount
/dev/disk2
Projects-Mac-mini:mount_cwd projectzero$ ./flipflop2
======================================================
BSD process name corresponding to current thread: umount
Boot args: -zp -v keepsyms=1
Mac OS version:
18G87
Kernel version:
Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64
Kernel UUID: 982F17B3-0252-37FB-9869-88B3B1C77335
Kernel slide: 0x0000000005000000
Kernel text base: 0xffffff8005200000
__HIB text base: 0xffffff8005100000
System model name: Macmini7,1 (Mac-35C5E08120C7EEAF)
System uptime in nanoseconds: 390113393507
last loaded kext at 197583647618: com.apple.filesystems.msdosfs 1.10 (addr 0xffffff7f89287000, size 69632)
last unloaded kext at 61646619017: com.apple.driver.AppleIntelLpssGspi 3.0.60 (addr 0xffffff7f88208000, size 45056)
[...]
======================================================
Macos xnu missing locking in checkdirs_callback() enables race with fchdir_common()