Serious Security Vulnerabilty In Apple OS X Leopard

An unpatched security hole in Apple's OS X operating system could be used by attackers to change key system settings or to take control of vulnerable computers, security researchers warn.

In a posting to news-for-nerds site Slashdot.org on Wednesday, an anonymous reader noted that a core component of OS X 10.4 (Tiger) and 10.5 (Leopard) called Apple Remote Desktop Agent could be leveraged by any user on the machine to install new programs or alter important system settings. Generally, these tasks are reserved for only the "root" account -- the most powerful user account on the system -- or at the very least they require the user to first enter a password for the requested changes to take effect.

The security hole has to do with the fact that ARDAgent accepts commands from Applescript, the scripting language built into OS X. As a result, a simple one line script can force ARDAgent to load any programs as root -- regardless of whether the Applescript command was invoked using an administrator/root account or from a less powerful "standard" user account. The commands are executed without ever prompting the user to enter his/her password.

To see why this is a big deal, open up a Terminal in OS X using a standard account (use Spotlight if you don't know where the Terminal is located), and cut and paste the following command:

osascript -e 'tell app "ARDAgent" to do shell script "whoami"';

It should return a single word: "root". All we did here was use Applescript to force ARDAgent to tell you which user account ARDAgent was being run under. But we could have just as easily told ARDAgent to do something a lot more dangerous. As one Slashdot poster noted, we could have passed it an Applescript command to silently disable the built-in firewall and open specific pathways into the machine so that anyone nearby or on the same local area network could connect directly to it unchallenged.

While most of the coverage of this vulnerability so far says it exists in both OS X 10.4 and 10.5, I could not get the test script to work on my Tiger installation, and all attempts to exploit this on the systems of other 10.4.11 owners I spoke with generated the same error message: "AppleEvent timed out." It worked flawlessly on numerous 10.5 machines in use at washingtonpost.com, however.

Interestingly, Apple has advised users that this isn't a big deal. In a post to its support forum on June 8, 2008, Apple acknowledged the issue, but said it was "not a cause for concern." I pinged Apple on Thursday to find out if they plan to issue an official fix for this problem, and I will update this blog in the event I receive a response.

While I have seen claims that this can only be exploited by someone who has physical access to a vulnerable 10.5 machine, several experts I spoke with say that's simply not true.

For example, an attacker could bundle one of these malicious Applescripts in an installer program for a downloadable OS X application. Alternatively, the attacker could use this in combination with another exploit -- say a weakness in the Safari Web browser -- to affect lasting and potentially devastating changes on a victim's machine.

"A remote attacker would need to successfully attack your web browser or another program on your computer," said Jay Beale, senior security analyst and co-founder at Intelguardians, and the creator of Bastille UNIX, a script-based approach for securing various operating systems, including OS X. "But attackers find that easier and easier now, either by putting a browser exploit in an advertisement on a Web site you view or just luring you to a hostile Web site."

The good news is that this is fairly easy to fix. I asked our Mac experts here at washingtonpost.com to test this stopgap fix provided by a Slashdot reader. The remedy worked for them, but your mileage my vary depending on how you've set up your system.

Beale offers another -- perhaps more elegant -- approach, one that actually takes advantage of the vulnerability in order to fix itself. He suggests using an Applescript command that tells ARDAgent to change its behavior so that it can no longer be invoked by non-root users. The beauty of this approach is that it only alters settings on systems where this vulnerability exists. To do this, copy and paste the following text into Terminal:

If you run the test exploit script again, it should then list your user name instead of root.

Even if this vulnerability were limited to exploitation by local users (anyone with physical access to a Mac), it would still be fairly serious. While I do not spend much time writing about local attacks, they are in many senses more difficult to defend against. If a determined attacker has physical access to the system and some time to work, it is pretty much "Game Over" after that.

That goes doubly for Microsoft Windows systems. This vulnerability with Mac OS X reminds me of a stunning video I saw recently of the damage that a novice attacker can inflict on a Windows system merely by booting the computer up straight from a version of Linux burned to a CD, such as "Backtrack," the security tools version used in this clip. Backtrack allows you to boot into Linux from the CD and then view and or even modify core Windows system files stored on the underlying computer hard drive.

In this video, the would-be attacker navigates to the Windows\System32 directory, and renames "Utilman.exe," the program name for the Windows Utility Manager (a simple program that handles text-to-speech applications and other helper programs). You can open the Utility Manager on Windows XP or Vista anytime by pressing the Windows key and the "U" key at the same time.

The important thing to note about the Utility Manager is that regardless of whether you're running Windows from the all-powerful administrator account or a limited user account, Utility Manager always runs using the built-in SYSTEM account on Windows, which is just as powerful (if not more so) than the Administrator account.

In the video, the attacker then simply renames the Windows command prompt -- which can be used to start or stop any program -- changing its name to Utilman.exe. When Vista starts up and presents the attacker with a login screen, the attacker bypasses that by pressing "Windows-U". Sure enough, Windows invokes what it thinks is the Utility Manager. Instead, the command prompt pops up, allowing the attacker to enter "explorer.exe" and access the Windows desktop using the powerful System account.

Damn, root without authentication. Thanks Apple. Of course it's 'Not a concern'. Thanks for providing a workout Brian. Now I think the next thing I'm going to do is delete ARDAgent. After that, I'm going to hunt for this malware. I wonder if RBN has it. Maybe 85.255.xxx.xxx does.

If you can get a machine to boot off of your CD, it's "Game Over" no matter what system it's running. The Utilman route is interesting because it's (a) incredibly easy and (b) not immediately obvious to the average user. But if I can write to any file on your hard drive, I own your system. Period.

So many people seem to want to discount this based onthe need of getting some user interaction.

I've got a newsflash for you. A large portion of the Mac community believes that their machines are untouchable. Acting with that belief, they are actually easier to trick into downloading and running a file. After all, in thier minds, what could possibly go wrong?

The human factor makes this a very viable exploit. The fact that many security savvy Mac users are dismissing this because they know not to run strange and untrusted code is a bit presumptious. I find that the majority of users, regardless of platform, are true end-users and are the reason that things as silly and trivial as the Storm worm continue to propagate. A simple email blast with this code as an "e-card" would probably net you a fair amount of Mac users too.

'I've got a newsflash for you. A large portion of the Mac community believes that their machines are untouchable. Acting with that belief, they are actually easier to trick into downloading and running a file.'

Too right.

'The fact that many security savvy Mac users are dismissing this because they know not to run strange and untrusted code is a bit presumptious.'

Slightly. Everyone assumes an attack has to be automated. Foolish thinking.

'I find that the majority of users, regardless of platform, are true end-users and are the reason that things as silly and trivial as the Storm worm continue to propagate. A simple email blast with this code as an "e-card" would probably net you a fair amount of Mac users too.'

"Alternatively, the attacker could use this in combination with another exploit -- say a weakness in the Safari Web browser -- to affect lasting and potentially devastating changes on a victim's machine."

This should read, "... to effect lasting and potentially devastating changes..."

How is that "doubly" for Windows?
Boot any system to another OS using a boot CD or USB drive, and you own it. I'm trying to figure out how (unless you're saying that this is "infinite pwnership", and that double infinity is infinity) you reckon that Windows is somehow "doubly" vulnerable to local physical access attacks.

"That goes doubly for Microsoft Windows systems. This vulnerability with Mac OS X reminds me of a stunning video I saw recently of the damage that a novice attacker can inflict on a Windows system merely by booting the computer up straight from a version of Linux burned to a CD, such as "Backtrack," the security tools version used in this clip."

Having an attacker gain physical access to a machine and be able to compromise it does not make it 'Doubly' worse for a Windows machine unless you're an idiot.

If the attacker has enough access to be able to boot the machine to a CD, then no OS in the world can prevent this. If you have Bitlockered (or some other form of full volume encryption (FVE)) the drive, this Backtrack attack fails. I don't know if there are FVE tools for Apple computers but if there aren't then Apple can't defend itself from it. So if anything could be 'doubly' worse for Apple computers.

This isn't new, and it certainly isn't doubly worse for a Windows machine. Please...buy a clue. Stop trying to be sensationalist just to get readers.

Matt's right, the Disk Utility SUID warning is unrelated to this. The Disk Utility warnings are an issue with either Disk Utility, Software Update, or the Mac OS X 10.5.x updaters themselves -- they're not an issue with ARDAgent, even though Rixstep is confused and thinks the messages are related to this security hole.

Brian,
I copy/pasted your command string (including the semicolon) into the command line of a terminal window. It returned a screen full of hex numbers and text to the effect that 'No pool existed' with the final line:

"Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired."

means that Apple knows (and diskutil correctly reports) that ARDAgent.app has the setuid bit. This was by design; in order to perform its administrative functions and allow remote admins to run scripts as root, ARDAgent needs to be setuid. The diskutil warning, as such, did not mean Apple "knew there was a problem" at that time.

The problem comes up because ARDagent's AppleScript dictionary includes the 'do shell script' command, which can be maliciously employed.

which removes the setuid root permission on the utility in question but not root's write permission.

The 555 setting does the job, but it removes write permission from the file for the owner (in this case root). Removing root write permission from the file may prevent a future patch from Apple from being deployed, since it removes root's authority to change the file.

but on my 10.5 system. At the recommendation of a co-worker, I toggled ARD off and on, executing the osascript each time, and then it returned "root" as the answer. I have now gotten the "root" answer on both 10.4.11 and 10.5.3 systems.

If you enable bitlocker on Vista you won't have any of the above described windows problems. If you think there is a chance someone may gain physical access to your Vista machine, for the sake of sanity, you MUST enable bitlocker.