Slashdot Mirror
Mac OS X Root Escalation Through AppleScript
An anonymous reader writes "Half the Mac OS X boxes in the world (confirmed on Mac OS X 10.4 Tiger and 10.5 Leopard) can be rooted through AppleScript: osascript -e 'tell app "ARDAgent" to do shell script "whoami"'; Works for normal users and admins, provided the normal user wasn't switched to via fast user switching. Secure? I think not." On the other hand, since this exploit seems to require physical access to the machine to be rooted, you might have some other security concerns to deal with at that point, like keeping the intruder from raiding your fridge on his way out.
ARD = Apple Remote Desktop You can remove it by following these instructions.
I might be misinterpreting you, so I apologize if I am. However, it sounds like you're saying that in order to have this code work, "Screen Sharing" needs to be enabled in the Sharing preferences. This is not true.
Even as a normal user on my mac, the exploit code works.
:wq
This does not work over ssh, at least not if you user isn't also logged in physically to the machine. If you try over ssh, it gives the error
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
However, it does work if you have a remote desktop view into a machine.
:wq
Nope. You cannot do it via SSH unless that account is already logged in physically, at the console. versus:Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)
Other reply -- Medieval_Gnome -- is absolutely correct. Unless you've DELETED by hand the Apple Remote Desktop files, the exploit works. I do not have ARD enabled, and the exploit works.
The AppleScript requires an account to be logged in at the console. Granted, it's possible to also do that remotely, but you still need to have the console avilable via VNC etc.
Actually, the above only occurs as I had 'su'ed to another user, then ran the above command. If, instead of using su I simply try to touch a file in the second account, it works just fine. So I retract the above.
-Ryan
AUWYHSTOT (Acronyms are Useless When You Have to Spell Them Out Too)
That's it:
% ls -l-rwsr-xr-x 1 root wheel 1439952 Nov 15 2007 ARDAgent
Time to run find(1) to see if there are any other things like this.
And, I should say, as a so-call Apple fanboy, I am deeply embarrassed. It's been decades that people have known to watch out for stuff like this.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
I've got it to run destructive things as an ordinary user without any need for authentication beyond being logged in
% osascript -e 'tell app "ARDAgent" to do shell script "echo Nasty Content >Nasty Content
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
Assumptions:
AppleScripting is only applicable to
"do shell script" is only a problem in the main binary, suid stuff in Resources/ isn't impacted.
Results: Now, I have one of the machines where this exploit isn't working: So, somebody out there who can get it to work, see if: works or not. That might need full pathing, I'm not sure.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Just embed the script in an applescript *.app executable, which many clueless users (I know, I am a Mac sysadmin to some of them) will click on, despite the warnings from the system on trying to start an executable from Mail and on first launching the app.
It's almost like Anna_Kournikova.jpg.vbs all over again.
Here's a non-destructive way to neutralize it.
/System/Library/CoreServices/RemoteManagement/
cd
sudo tar -czf ARDAgent.app.gz ARDAgent.app
sudo chmod 600 ARDAgent.app.gz
This simply hides it in an unreadable tarball.
Some drink at the fountain of knowledge. Others just gargle.
A remote terminal session doesn't get you access to the OS X GUI, which is where AppleScript is found.
http://alternatives.rzero.com/
I don't think the GP was saying that you need to have Screen Sharing enabled for the exploit to work at all; you need to have Screen Sharing turned on for someone to run the exploit without physical access to the machine.
I.e., you can't run it over an SSH session; you need the Finder. The only ways to get access to the Finder are either physically, by sitting down in front of the computer, or by using a screen-sharing application like Screen Sharing (Remote Desktop), or VNC.
That was my understanding, at least.
The exploit works, if you have physical access to the machine, regardless of whether you have Screen Sharing enabled or not. However, it's when you have Screen Sharing turned on that it's possibly a remote root to anyone you let access your screen.
It's a bad vulnerability and one that I'd like to see Apple fix ASAP, but it's several steps down from a true unprivileged remote root. It might have negative consequences for shared and lab machines, but for most home and office users it doesn't seem like it means much, unless you typically allow lots of people remote-desktop/VNC access.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
True. But presumably you could write the script in any of the command-line editors and save it to the desktop or something, at which point the user could click on it.
Not that it matters. If you have that level of access, you're already in a position to do more damage than what you could do through this exploit, by the sounds of it.
How are sites slashdotted when nobody reads TFAs?
Users noticed in October that Apple's built-in file system permissions verifier really wanted to delete the ARDAgent program (along with several others) because it was user-executable and setuid root. None of the users seemed to understand exactly what this meant...
Apple's reported fix, and I am not making this up:
The entire text below, in case Apple deletes it:
Mac OS X 10.5: Disk Utility's Repair Disk Permissions reports issues with SUID files
* Last Modified: June 06, 2008
* Article: TS1448
* Old Article: 306925
Symptoms
The following messages may appear in the Disk Utility log window when repairing disk permissions.
Warning: SUID file "usr/libexec/load_hdi" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources/DiskManagementTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/Locum" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/runner" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/readconfig" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/writeconfig" has been modified and will not be repaired.
Warning: SUID file "usr/libexec/authopen" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/Finder.app/Contents/Resources/OwnerGroupTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.
"Any message that starts with: 'ACL found but not expected on...'."
Products Affected
Mac OS X 10.5
Resolution
You can safely ignore these messages. They are accurate but not a cause for concern.
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
The user wouldn't need to do anything. If you log in via SSH as a limited user, you could (theoretically) use OS X's "open" command to launch the file as if it was clicked, from anywhere in the filesystem. The catch is that your SSH login must be the current user of the Window Server (locally logged-in).
True science means that when you re-evaluate the evidence, you re-evaluate your faith.
This may have come too late in the comments for anyone to see it, but if the exploit is active on your system, adding a key to ARDAgent's Info.plist makes the problem go away without disabling ARDAgent altogether. (Whether or not ARDAgent is a security vulnerability itself is another story.)
That "YES" is not a typo; setting it to "NO" does not fix the problem. AFAICT this makes osascript expect that ARDAgent will implement more of its own AppleScript handlers...which of course, it doesn't.
P.S. I searched for other, similar problem setuid apps, and turned up check_afp.app (which someone else posted already) and, surprisingly, GoogleUpdaterInstaller. Fortunately, even though these apps run setuid, they won't respond to the "do shell script" attack.
So someone has to be logged into the Desktop at the same time the command is issued (even if issued remotely) and I'm guessing that the account the remote user is logged into probably has to be the same account the desktop user is using.
So Xserve servers should be immune to this via SSH, unless someone else is actively using Remote Desktop at the same time. Interesting!