Filed under: Security
ARDAgent setuid allows root access, but there's a sort-of fix
Updates: See the end of the post for current info.
We've been getting quite a bit of email since yesterday's anonymous Slashdot posting of a security problem with ARDAgent on Mac OS X 10.4 and 10.5, and there's plenty of Twittering going on over the issue.
Here's the deal: ARDAgent is the application that responds to Apple Remote Desktop remote administration requests, screen sharing and the like; you can find it in /System/Library/CoreServices/RemoteManagement on 10.5 machines.
In order to go do the voodoo that you do so well when you're administering remote Macs, ARDAgent needs to be 'setuid root' -- it needs to run with the privileges and access that belong to the system administrator, the same way you do temporarily whenever you unlock a system preference or install an application with Apple's installer. This is normal and expected behavior.
What's not so normal and expected is that ARDAgent will execute the 'do shell script' AppleScript command (on behalf of remote admins, normally, who need to run Unix commands from time to time). The problem here is that since ARDAgent is setuid root, any subprocess it launches is running with administrator permissions, and in fact with the right malicious scripting here it would be possible to do a great deal of damage. Granted, in order to activate this vulnerability the attacker would either have to be at the machine, or logged in remotely with the same account that is currently in use... or just convince the user to run a malicious downloaded application. Yikes.
The good news is, there's a very simple workaround (courtesy of the fine folks at Intego -- note that if you actually use VirusBarrier to disable ARD's shell script access as they recommend, and your machine is managed remotely, your administrator may take some umbrage). It turns out that if ARD's remote access features are turned on, via the Sharing pane in System Preferences, you're clear. Even if there aren't any users permitted to administer your machine, the 'do shell script' command that ARDAgent runs is neutered and cannot be exploited in this fashion. Most home and small office Macs wouldn't normally have this turned on, but once you activate it you should be protected. Our basic instructions can be found here. [See update below -- turns out the fix may not protect you fully.]
Stay safe out there!
Update: Thomas Ptacek of Matasano weighs in on this flaw and offers some additional workarounds, but he doesn't seem overly concerned.
Update 2: Commenter (and Mac OS X security pro) Zack Smith, along with Chris Barker, points out that it's possible to kill the ARDAgent process and immediately run the osascript command, which bypasses the protection that running ARDAgent under launchd provides. Under those circumstances an attacker or someone sitting at your machine could still run commands as root, much to your chagrin.
To prevent this, one approach is to change the permissions on the ARDAgent application bundle -- note that this will both break with future system updates or permissions repairs, and may adversely affect administrative access to your machine from legitimate managers:
sudo chmod -R u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app
You can also simply archive and remove ARDAgent.app if you don't plan to be managed by anyone.
Thanks to everyone who sent this in, and thanks to Intego for pointing out the workaround.

![TUAW [Cafepress]](http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-cafepress-promo.png)


Reader Comments (Page 1 of 3)
kurt.tappe said 2:42PM on 6-19-2008
Wow--the tricky bit here is that the solution is 180 degrees contrary to what you'd expect. Few would think the ARDAgent is even enabled if remote access is off, and that the ability to run as root would be exclusive too the service being enabled. I'd expect Apple to fix this by having the service truly off if the option is off in Sharing--seems not only straightforward but a way to reduce unnecessary CPU and network usage as well.
Reply
kirkmc said 3:02PM on 6-19-2008
It's not running, actually, or enabled; it's just an application that's called by the one-line AppleScript. ARDAgent doesn't use any CPU at all. However, it does run - and use very little CPU - when Remote Management is on.
Joey Celis said 3:56PM on 6-19-2008
I agree it seems a bit backward. If its uncheck then the service should be off.
Either way I did the fix. Thanks TUAW for keeping my mac safe!
whoami said 2:57PM on 6-19-2008
i think apple needs a "fight the smears" site! ;)
if anyone has physical access to your machine, it's game over....
Reply
Michael Rose said 3:18PM on 6-19-2008
Physical access isn't needed, you could be running a malicious app and it would have root privs.
Tony said 4:15PM on 6-19-2008
That's like saying Internet Explorer is secure because you have to be logged into the machine.
This allows root access... apple will hopefully fix it within a day or two but it's a pretty big hole whilst it lasts.
Rather than configure your mac to run a known insecure binary (which is utterly backwards to me), just run sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent and it'll fix the problem permanently.
Daniel M said 3:56PM on 6-19-2008
That's funny, I just released a Virtual Appliance that can use multiple Vine Servers to simulate a halfway-decent Mac OS Terminal Server. A G5 Quad would be awesome for that!
http://desktopecho.com/iMKS/
Reply
Stephanieanie said 4:10PM on 6-19-2008
Uh oh?
http://www.macshadows.com/forums/index.php?showtopic=8640
Reply
rpop said 4:14PM on 6-19-2008
Your "fix" isn't really a fix, as it seems this would leave machines unable to be controlled through Remote Desktop.. which is the whole point of having ARDAgent running to begin with.
Reply
Tony said 4:18PM on 6-19-2008
Yeah, but there's a choice here:
1. No remote admin
2. All your macs are rooted.
Take your pick.
Michael Rose said 4:52PM on 6-19-2008
Rpop -- if you actually want machines controllable with ARD, then leave the users listed that you want to have access. The fix applies for people who never had ARD turned on to begin with, not those already under management.
JoshK said 4:15PM on 6-19-2008
Is there someway to do remote desktoping on Macs for free? I've been helping an employee with her new Mac and tweaking settings when she's not there. One problem is that when she's not there I have to have someone else sign into iChat to accept the screen share request. I really don't want to pay $300 or $500 for Apple's software. Doesn't that seem like a bit much?
Reply
gm said 11:55PM on 6-25-2008
Yes, there is a way:
VNC server for Mac OS X: http://www.redstonesoftware.com/products/vine_server/OS_X
VNC client for Mac OS X:
http://sourceforge.net/projects/cotvnc/
I've used these two quite successfully.
Chris said 4:41PM on 6-19-2008
This is not a fix. All this is doing is have ARDAgent run as you, not as root.
Since it is running as you, a script you run can also kill it, call the osascript again, and go on its merry way. so far it appears the ardagent restarts as setuid root.
In short, intego's fix isn't a fix.
Reply
Michael Rose said 4:52PM on 6-19-2008
Chris, are you referring to tony's fix above (changing permissions on ARDAgent) or simply turning on Remote Management?
If Remote Management is turned on, you cannot use 'do shell script' via ARDAgent. Try it and see. It survives a restart.
http://www.tuaw.com/ardfix/
Zack said 4:57PM on 6-19-2008
turning on remote management will not work as you have just kill the process as its running as your user account.
Chris said 4:59PM on 6-19-2008
michael- Your fix is to enable ARDAgent fully. Which has ARDAgent running as the logged in user (instead of root). Since it is the current users process a script running as them can kill ARDAgent, call the osascript immediately, and it will be running as root again.
Try this: Get the PID of ARDAgent with the following command (the first number in the string)
ps ax | grep ARD
Then:
kill PID#; osascript -e 'tell app "ARDAgent" to do shell script "/usr/bin/whoami"'
You will still get a response.
Zack said 4:51PM on 6-19-2008
Yeah as I mentioned to Chris , you can just kill it off when its running under your account. Granted you would need to run the exploit as the console user but it still bypasses their "fix", the title needs to be changed.
Reply
Zack said 4:54PM on 6-19-2008
By their I actually meant, TAUW's no integos by the way
Michael Rose said 5:12PM on 6-19-2008
Zack, when ARDagent is enabled via the Sharing panel of System Preferences it's true that it does run in the user context -- but it's launched by launchctl, not by the user, and killing it simply causes it to respawn in the same state. The privs escalation will not work if ARD is enabled in the sharing pane. Try it and let me know your results.