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."
More Micro$oft FUD.
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
MAC's' don't get viriis or roots access - that's a windows problem!!!
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.
Is Twitter used in any way, or is the headline just looking for a ultra modern and hip way to say "small"?
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.
Obviously they were boot-camping a Mac and didn't notice that they had the Windows side booted when the exploit happened.
Whew, that was a close one!
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.
Just tested this on my Mac in OS X -- grants root level access immediately.
What story? The summary days it all! Macs are full of viruses.
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!
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.
No, you're the one that's stupid, because you failed to see that the OP was being sarcastic.
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
A use for twitter.
Comment removed based on user account deletion
I don't think there's a single non-sarcastic post here!
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.
Oh right, thats yet another thing the apple marketing machine lied about.
Many exploits in the past have been under 140 bytes.
Here's a quick fix for today:
1. Open terminal. /usr/bin/sudo /usr/bin/OTHER" /usr/bin/sudo /usr/bin/FAIL /usr/bin called "sudo" to a file at /usr/bin called "FAIL" /usr/bin/DAMN-IT-APPLE /usr/bin/sudo
2. Type "su [administrative user name]" and your root user's password.
You'll need to do this because of course, you're NOT using an administrative account for day to day purposes, because you're not a moron.
Of course, if the account you use for daily tasks is unprivileged (as it should be,) this security flaw shouldn't, (operative word!) even affect you because the account is not in the sudoers file in the first place. RIGHT?!? (After typing this, I went and tried it. First I verified I was in my "me" account, which is UNPRIVILEGED. I then copied and pasted the text from the Register's website into the terminal, and ran a command to verify whether or not I had suddenly conferred upon my previously unprivileged account ROOT privileges. I wasn't expecting it to work. But holy shit, yes it sure did. I then went in using visudo run as root and deleted the new entry, but DAMN IT ALL APPLE! Then I had to remove a new directory I created as a test somewhere my unpriv'd user should NOT have been able to create one, but WAS able to. FAILURE, APPLE. HARDCORE FAILURE!
3. Type "sudo su" and your root user's password again. This will give you the "sh-3.2#" prompt in OS X 10.10.4. If you give it the command, "whoami" it will reply, "root". This will make you able to do anything that can be done on your system. In case you didn't know, when you first set up a Mac, and tell it your user name, it sets both THAT user to be an administrator, AND it set's "root"'s password to the same thing you set your user's password to be, even though they, (your default/first user and root,) are technically in reality TWO different users. Apple (or a precursor Unix they used to build OS X) does mitigate the security problem they built in by making it so that your privileged account you set up can't do just ANYTHING and still requires using "sudo" to do things only root should be able to do. It's not much, but it's something.
4. Type "mv
Here, "OTHER" is SOME OTHER NAME that YOU pick. Just to be clear, if you want to rename it "FAIL", the command is:
mv
This will rename (move) the file at
To undo this, should you need to, if you picked instead, DAMN-IT-APPLE for the name, to restore "sudo", you'd do this:
mv
Get it? The syntax is "mv" (meaning MOVE) "/usr/bin/[whatever you named it]" (TO or BACK TO) "/usr/bin/sudo".
More simply, that's "move source destination" or "move old-name new-name".
Pick a new name you'll be able to remember for the sudo program. If some script or malware or jackass with access to your computer can run this code, and needs then to use sudo to do any damage, and doesn't know what sudo is now called, then hey! Can't use what you can't find!
Make note of the new name. Now when some piece of malware or some user somehow accesses your machine and runs sudo, it WON'T BE THERE!
It's important to remember the new name of the program, as anything requiring sudo will require you either to make an alias to it, or rename it back.
Also, be aware if YOU use it, that you need to clear out your bash history, by going to your home directory, "~" and executing "rm .bash_history" and/or "rm .sh_history" so no one can just look up to see what your renamed sudo command is, every time you use your newly renamed sudo.
5. THIS IS IMPORTANT: when you're done mucking about with a privileged account or as root, type "exit" and press enter. This will terminate the shell that opened as each level of user privilege or change you executed. If you started as "me" (your unpriv'd acct) and "su"'ed to "privileged/admin user" and then did "sudo su" to get to root, the first exit will t
Granted, as others pointed out, physical access is the end of the road, not being able to access the command line.
But even if you have the device, decrypting it is a major challenge, especially if you want to write to the disk.
I don't think adding to sudoers would be very easy or quick on an encrypted hard drive.
None of my AC posts seem to stick for some reason. Or I don't understand how /. works these days, if it does. Whatever I write, I just can't find, regardless of filter settings, a day later. And yes, I'm always AC.
Anyways... In a day where every vulnerability needs a catchy name to get exposure, I've got a suggestion for this. It's using dyld, to gain sudo priviledges, right? So, combine dyld and sudo, end up with "dyldo". That's a name which already gets you thinking of holes, and penetration testing, and other related subjects. If only I'd had a twitter account to suggest this to ic0n1c directly :(