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

See.....

[8127972]

Twitter is bad for you. At least if you're a Mac user.

Re:See.....

[Noah Haders]

I could not imagine a metrosexual urban hipster at burning man. lol. my favorite part about the event is that there are actual signs that say "no shirtcocking". it's ok to be clothed, it's ok to be naked, but to wear a shirt and no bottoms is creepy.

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.

Re: See.....

[omnichad]

The SMS size limit is different depending on the network/carrier. Tweets are a standard size (to hit the LCD of SMS carriers).

Re:See.....

[DaphneDiane]

You can also just boot from an OS X image, for example download the OS X installer extract the installESD.dmg file ( typing from memory but pretty sure that is the name ), install that to a USB drive and boot from it holding the option key when the computer starts up. ( again typing from memory might be command-option or the like ) In fact depending on the age of the computer it might already have a recovery partition that you can just boot directly from and then launch disk utility to mount the main partition and terminal to fix it.

Esserwhich?

[Myria]

It's just Stefan Esser, as far as I've known for the last decade.

Misleading and Hyperbolic Title/Comparison

[Galaga88]

Fact[0]: The code for this exploit could fit within a tweet (which is to say: 140 characters.)

Fact[1]: Despite referring to tweets and Twitter, this exploit can't occur via Twitter. The attacker already has to have local access.

A lot of security exploits could fit within a tweet, but I've never seen that comparison before. It misleads people into thinking that you can pwn a Mac via Twitter.

Re:Misleading and Hyperbolic Title/Comparison

[OzPeter]

A lot of security exploits could fit within a tweet, but I've never seen that comparison before.

You're right .. they should have specified it in pico Libraries of Congress. At least that's a unit of measurement that most people here would understand.

Re:Misleading and Hyperbolic Title/Comparison

[fyngyrz]

Furthermore, local access pretty much is the end of the road anyway. Boot from the right CD with a custom filesystem that ignores HD filesystem permissions and yet allows you to set them any way you want, system is now wide open. Replace a few choice commands that you know are going to run, and bang, fully compromised. And that's just one of the many easy ways in to access as the system stands. You can also copy off the entire HD, or for that matter, erase it. Or both. You can compromise a command for a way in, copy an otherwise encrypted volume and walk off with it, break the encryption at your leisure, then use the previously installed compromise to get in and cause mayhem.

If you don't have physical security and there is any kind of local threat of compromise, you could become toast at any time. These kinds of "threats" are insignificant in the larger scheme of things. If you need local security, the only sufficient mechanism is to physically deny access to the computer.

Re:Misleading and Hyperbolic Title/Comparison

[Anonymous Coward]

well considering the last exploit was related to special characters in a text message, it's reasonable that the person who didn't read the article would make that mistake.

But yes, you'd need to be at the box locally for this to be worrisome. I work at a university who's still in the process to migrating people from MAC to PC, so there's tons of apple tech on site, this bug would allow anyone, student, janitor, some dude of the street, to walk up to a machine, login as guest to view the web, then own root.

It's bad, but not "omg the world is ending bad"

MAC users should be happy that so much attention is directed at them currently, it's good for us all.

Re:Misleading and Hyperbolic Title/Comparison

[Galaga88]

You're right .. they should have specified it in pico Libraries of Congress. At least that's a unit of measurement that most people here would understand.

So says you. I'm working on a patch for ext4 right now to display file sizes in kilotweets, megatweets, and teratweets.

Re:Misleading and Hyperbolic Title/Comparison

[PopeRatzo]

But yes, you'd need to be at the box locally for this to be worrisome.

Or, you just need someone gullible to be at the box locally.

Given that we're talking about Apple products, it might be cause for concern.

Re:Misleading and Hyperbolic Title/Comparison

[mlts]

I do agree that it isn't a remote root shell hole, but it can be combined with something like the SSH brute force vulnerability or another attack that can execute shell commands as an unfettered user... and then the box is compromised.

The good thing is that Macs have functionality similar to SELinux as well as sandbox capabilities via the App Sandbox. This should be something used by all programs whenever possible, since it allows the OS to isolate the program from the rest of the filesystem and OS, helping mitigate a compromised program.

Hopefully Apple can issue a fix in a short amount of time, because this is an easy exploit to use, and combined with something like a broken Java variant, could be used via the Web browser to hijack the entire box.

Re:Misleading and Hyperbolic Title/Comparison

[bidule]

"sudo rm -rf /" also fits in a tweet. It will even ask for the password which their exploit isn't capable of.

Re:Misleading and Hyperbolic Title/Comparison

[Penguinisto]

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

Known vulnerability?

[TwentyCharsIsNotEnou]

Already fixed in the (preview) next OSX version - is that by luck or design?

Makes me wonder how many known vulnerabilities Microsoft / Apple / Google have on their buglist that will only be fixed when they become publicly known.

Twit

[Anonymous Coward]

As small as a tweet and still too big to fit in the summary.

Oh ffs.

[Harold Halloway]

Well done. You realise that this story will be reported in tomorrow's Daily Mail as 'Twitter Steals Apple Users' Bank Details'?

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

Negative

[xdor]

Just tested this on my Mac in OS X -- grants root level access immediately.

Re:Negative

[93 Escort Wagon]

Just tested this on my Mac in OS X -- grants root level access immediately.

Yup - even if you're a non-privileged user.

Since most people are running with administrator accounts (which is dumb), I thought that might've been necessary - but it worked from an account that didn't have sudo access.

Are You Sure?

[xdor]

Local application access!

I'm still trying to determine if this would be effective JavaScript Shell

You just have to be able to set an environment variable no matter who you are and you're root. It's just a question if FireFox has its own "environment" or relies on an under-privileged UNIX account.

From what I can tell, this is a wide-open window. Huge, huge, flaw.

Re: How the hell does this get into live software?

[markus]

The bug is stupid. No doubt about that. But it's not quite as stupid as you think.

The bug is not actually in the setuid application, but it is in the system wide dynamic loader that is needed to execute the setuid application.

So, a naive programmer could be excused to think that they don't need to worry about security as it is not immediately obvious that the code executes with elevated privileges.

Of course a more seasoned developer should have noticed. It's not that difficult to spot, especially as dynamic loaders are known to have had security bugs before. I think even Linux was affected at one time.

Re:Explains It

[Galaga88]

Is it a wireless keyboard? Could the um, batteries be going out? Or maybe Bluetooth interference?

I'm just not sure I'd jump straight from malfunctioning keyboard to rooted, even if my firewall wasn't up. Is your router even forwarding any ports to your Mac?

Sarcasm...

[moosehooey]

No, you're the one that's stupid, because you failed to see that the OP was being sarcastic.

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.

Please explain more

[goombah99]

Reading the explanation here: https://www.sektioneins.de/en/...
I don't fully understand how it works, but it seems to be more complex than what you just said. I suspect it depends on a parent process inheriting a child procesess setuid for accessing a file.

the bash script however is a riddle to me. I don't understand how the pipe to channel 3 ends up in the /etc/sudoers file. Where does channel 3 go. I suspect the newgrp statement is there to just be any process which does a setuid as root. Not sure. Again I don't understand how it's being called here.

What does the environment variable look like as this executes? which parts of it execute when? and how does the echo get to the file.

the final sudo -s I understand.

can someone break this down for me?

Re: But can it be a Tweet?

[MSG]

When you run the example exploit command (simplified):
Your shell sets the DYLD_PRINT_TO_FILE variable.
Your shell executes newgrp. newgrp is SUID root.
As newgrp is initializing, the dynamic linker opens the value of DYLD_PRINT_TO_FILE (/etc/sudoers) for debug log output. It should check whether it is executing in a SUID context, but doesn't. It should also set the close-on-exec flag for that file, but it doesn't do that either. The log file is now file descriptor 3.
newgrp sets its uid and gids as appropriate for the calling user, and then starts a new shell. Because the close-on-exec flag wasn't set, the new shell still has /etc/sudoers open as file descriptor 3.
The new shell reads commands from stdin. In this case, it gets "echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3".
There is no more input, and the shell exits.
Your shell runs sudo. The sudoers file has been modified, and now says that you have the right to run all commands without being prompted for a password.
You get a root shell.