Network News

X My Profile
View More Activity

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.

There are signs that Apple may have fixed this flaw in 10.4, only to reintroduce it again in 10.5. In any event, Apple has known about this problem since last October, according this forum discussion posting.

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:

osascript -e 'tell app "ARDAgent" to do shell script "chmod 0555 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent"';

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.

By Brian Krebs  |  June 20, 2008; 1:46 PM ET
Categories:  From the Bunker , Latest Warnings , Safety Tips  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   Del.icio.us   StumbleUpon   Technorati   Google Buzz   Previous: Apple Issues Fix for Safari On Windows Security Flaw
Next: New Trojan Leverages Unpatched Mac Flaw

Comments

Why Apple thinks they are so secure?
I'd rather say "it is indeed a concern".

According to Symantec and other companies there's already a Trojan out (Ashtht) that can take over MacOS machines using this exploit just with a double-click.

It's just matter of time and we'll see probably also Zlob/Macsweeper gang adding this exploit to their MacOS malicious code.

Posted by: appleboooo | June 20, 2008 2:06 PM | Report abuse

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.

Posted by: debianbooooo | June 20, 2008 2:59 PM | Report abuse

I've got to say that's pretty disturbing. Apple is wrong to dismiss it.

All the scripts worked exactly as described on my 10.5 installation.


Posted by: John | June 20, 2008 3:29 PM | Report abuse

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.

Posted by: Nathan | June 20, 2008 3:33 PM | Report abuse

Regarding the windows "issue", physical access means the attacker wins. End of story.
http://www.kb.cert.org/vuls/id/789985

And the OS X issue in no way requires physical access.

Posted by: WD | June 20, 2008 3:50 PM | Report abuse

Uh, no. Even the malware approach requires someone sitting in front of the box to click on the malware. It's not a pure network exploit.

This is much ado about very, very little. If you have physical access to the box, you can get in. All it takes is an install CD to reset the password on any account, including root.

Posted by: rosignol | June 20, 2008 4:10 PM | Report abuse

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.

Posted by: Charles Decker | June 20, 2008 4:19 PM | Report abuse

'But if I can write to any file on your hard drive, I own your system. Period.'
'Regarding the windows "issue", physical access means the attacker wins. End of story.'

You both have to qualify that further.

'And the OS X issue in no way requires physical access.'

This is even more puzzling.

'This is much ado about very, very little.'

Typical naive fanboy chatter. Crafting a script to toast a system is child's play.

http://rixstep.com/1/20080620,00.shtml

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

Agreed.

Posted by: Rick | June 20, 2008 5:34 PM | Report abuse

>'Regarding the windows "issue", physical access means the attacker wins. End of story.'

Unless the system runs with a full drive encryption system such as Vista Bitlocker. You could then destroy data, but not gain control.

Posted by: Moike | June 20, 2008 5:44 PM | Report abuse

Slashdot also talks about a book on Foundations of Mac OS X Security:
http://books.slashdot.org/books/08/06/20/1412208.shtml
Why not print some excerpts and tips and examples from the book in your column?

After deleting ARDAgent, try NX.
http://nomachine.com/

Thanks, Brian.

Posted by: Singing Senator | June 20, 2008 6:20 PM | Report abuse

I don't get it, Why you security people and others act like little kids when a new flaw is found.

Bottom of page
http://rixstep.com/1/20080620,00.shtml

See this is why I like reading Security fix. Explains in detail what the flaw is and sometimes even provides a workaround. Others post "I told you so, I told you so. Macs are not secure" NO CRAP!!!

Rixstep, How old are you guys?! I would think professionals would act more professional then thinking only Apple users are smug. Sigh little children.

Posted by: LittleKids | June 20, 2008 6:37 PM | Report abuse

Just an FYI, the issue with SUID files in Disk Utility has absolutely nothing to do with this vulnerability.

Posted by: Matt | June 20, 2008 7:48 PM | Report abuse

matt: Apple acknowledged that there was a SUID issue with ARDAgent in that forum posting about diskutility:

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

You can safely ignore these messages. They are accurate but not a cause for concern."

Posted by: Anonymous | June 20, 2008 8:26 PM | Report abuse

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

Posted by: aeschylus | June 20, 2008 11:15 PM | Report abuse

I entered this text into terminal and got no response back except for the carrot.

Is there something I'm missing??

Posted by: RonC, Austin, Tx | June 21, 2008 2:19 PM | Report abuse

FWIW - Using Disk Utility to Repair Permissions will undo the "More elegant approach".


Posted by: Samuel | June 22, 2008 1:16 PM | Report abuse

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.

Posted by: Alun Jones | June 22, 2008 5:51 PM | Report abuse

I don't get this:

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

Posted by: RH | June 22, 2008 10:42 PM | Report abuse

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.

Posted by: Barry K. Nathan | June 23, 2008 1:54 AM | Report abuse

>>I entered this text into terminal and got no response back except for the >>carrot.
>>
>>Is there something I'm missing??

The complete command. A carrot simply means the command is incomplete.

Most likely cause: you forgot the single quotes.

Copy and paste it EXACTLY and it will work, at least in 10.5.

Posted by: BradS, Washington, DC | June 23, 2008 5:18 PM | Report abuse

Reports 'root' on 10.4.11 as well.

Posted by: Larry | June 23, 2008 9:02 PM | Report abuse

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

execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)

I'm running as an admin under 10.5.3.

Posted by: snowbird2 | June 24, 2008 1:04 PM | Report abuse

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:

execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)

I'm running 10.5.3 as an administrator.

Posted by: snowbird2 | June 24, 2008 1:21 PM | Report abuse

Inconsistent results here. I have both copy/pasted and meticulously typed in Terminal on 10.4.11, 10.5.3 and 10.5.x (undisclosed dev build) systems. Only the 10.5.x machine works (reports root).

The other systems return...

execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)

Anyone else get this response?

Posted by: JD | June 24, 2008 3:25 PM | Report abuse

Matt/Barry --

The diskutil warning:

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

Posted by: Mike | June 24, 2008 10:31 PM | Report abuse

Anyone know about Firefox or QuickTime vulnerability that would allow AppleScript execution while for instance watching a video in the web?

In other words:
- you click the mpg of flash video (no passwords, no installing codecs, no automated execution)
- the video starts playing

Question: is it possible that this AppleScript is executed altough the user (me) is not intentionally executing anything? Is there some vulnerability here?

Thanks.

Posted by: N.N. | June 24, 2008 11:20 PM | Report abuse

Another approach to block the vulnerability is to do:

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

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.

Posted by: Jeff G. | June 24, 2008 11:30 PM | Report abuse

Please note that changing permissions on the ARDAgent to clear the SUID bit is only a temporary solution.

In particular if the user repairs the permissions with the disk utility, the SUID bit will be set right back, making the user vulnerable again.

Posted by: Mario Grgic | June 25, 2008 8:29 AM | Report abuse

I also got the

execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)

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.

Posted by: Neil C. | June 25, 2008 3:40 PM | Report abuse

Anyone know if there's a browser sandboxing program like "SANDBOXIE" for a Macs?

Posted by: Tom | June 25, 2008 8:45 PM | Report abuse

There is a typo in the article:

osascript -e 'tell app "ARDAgent" to do shell script "chmod 0555 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent"';

should be 555 instead of 0555

Posted by: s. | June 26, 2008 2:05 PM | Report abuse

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.

Posted by: jrg | June 26, 2008 6:10 PM | Report abuse

Hi,

I got the following on OSX 10.4.11

osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: AppleEvent timed out. (-1712)

Can anybody tell over suggestions or answers to why the command timed out?

Posted by: Steve | July 2, 2008 1:11 AM | Report abuse

The comments to this entry are closed.

 
 
RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company