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 e mail since yesterday’s anonymous Slashdot posting of a protection problem with ARDAgent on Mac OS X 10.4 and 10.5, and there’s plenty of Twittering going on by 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.

digg_url = ‘http://digg.com/apple/Workaround_for_the_ARDAgent_vulnerability_on_Mac_OS_X’;

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. that 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 day 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 that vulnerability the attacker would either have to be at the machine, or logged in remotely with the same explanation 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 whether 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 whether ARD’s remote access features are turned on, via the Sharing pane in System Preferences, you’re clear. Even whether there aren’t any users permitted to manage your machine, the ‘do shell script’ command that ARDAgent runs is neutered and cannot be exploited in that fashion. Most home and small office Macs wouldn’t normally have that turned on, but once you activate it you should be protected. Our basic directions 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 that flaw and offers some additional workarounds, but he doesn’t seem overly concerned.

Update 2: Commenter (and Mac OS X protection pro) Zack Smith 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 that, one approach is to change the permissions on the ARDAgent application bundle — note that that will both break with future system updates or permissions repairs, and may adversely affect administrative access to your machine from valid managers:

sudo chmod -R u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app

You can additionally simply archive and remove ARDAgent.app whether you don’t plan to be managed by anyone.

Thanks to everyone who sent that in, and thanks to Intego for pointing out the workaround.

[Source] Michael Rose

windows explorer shuffle computer virus software laptop computers os x g4 windows xp sp2 software laptop