AppleScript flaw allows root access
updated 06:15 pm EDT, Wed June 25, 2008
AppleScript flaw
A MacNN forum poster reports on a serious flaw in Mac OS X's implementation of AppleScript. Essentially, applications that are running as root can accept AppleScript commands from applications that are not running as root -- and since every Cocoa application automatically gets some basic AppleScript support, this means that any time a Cocoa application runs as root, anyone else can send it a "do shell script" command and run other commands or applications as root. This is compounded by the fact that Apple ships an AppleScript application with its setuid bit set out of the box.
As described by the poster "If a GUI app runs as root, you've already got a problem, you say? Well, I said yeah, Cocoa and Carbon apps shouldn't be running as root, but this stuff does happen - badly written installers sometimes launch themselves as root, as do some utility programs, along with the popular lab management program 'iHook' - and it only takes one such screwup to allow hackers to root your computer. But no, they decided to flag it "Behaves Correctly" and ignore it."
Running the command:
osascript -e 'tell application "ARDAgent" to do shell script "whoami"'
will allow root execution.
The problem can be temporarily fixed by launching the Terminal and using this command:
sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
Also, don't repair permissions or it will undo the fix.











wow
06/25, 06:43pm reply
I hope that this gets fixed soon!
I can't imagine having Norton pop up on my MAC in LEOPARD asking me
"Application_Name is trying to run Process as root. Click allow if this is a trusted application..."
Would feel WAY to much like a M$ OS.
calverson
Mac Elite
Joined: Jul 2007
CharlesS
06/25, 06:59pm reply
With the intention of giving credit where credit is due, the "MacNN forum poster" is CharlesS. Nice catch. :)
ShadowKatana
Junior Member
Joined: May 2001
this just in...
06/25, 07:07pm reply
Good to see CharlesS has just started catching up on last week's news. (This has been on Slashdot since the 18th, and all over the place since then...)
jpellino
Fresh-Faced Recruit
Joined: Oct 1999
Props...
06/25, 07:10pm reply
CharlesS was on this on the 19th. It's MacNN who's just getting around to noticing what's on their own site.
jpellino
Fresh-Faced Recruit
Joined: Oct 1999
What happened to MacNN?
06/25, 08:00pm reply
MacNN used to be the among the first to report breaking Mac stories. This one is very old by now.
About the flaw, it requires either physical access to the machine, or an ssh'ed login. It's hardly exploitable in the wild, unless someone were to craft a social engineering-type application that a really dumb user would fall for.
leamanc
Fresh-Faced Recruit
Joined: Oct 2003
Same problem as before
06/26, 01:37am (1 reply) reply
I believe this is just a wider use of trick reported before as "remote access vulnerability". Right, CharlleS? First was reported as a method employed by a trojan to gain root access. So leamanc is right - essentially this does require physical access.
ViktorCode
Fresh-Faced Recruit
Joined: Jan 2006
Well
06/26, 02:24am (1 reply) reply
Yes, this is "just" the Apple Remote Desktop agent issue as of now, as only the ARDA app is scriptable and runs as root. The issue is that another hypothetical application running as root and allowing AppleScript access could/would show the same problem.
So Apple can quick-fix by not running the ARDA client as root, or they can try to make AppleScript "know" when a requesting application is not root and asking for a application which -is- root to do something. The latter shouldn't be too onerous, but the core problem here is that for Apple Remote Desktop to do much of it's goodness it does (as far as I can tell) need root/sudo access.
dimmer
Mac Enthusiast
Joined: Feb 2006
security
06/26, 07:51am reply
Again, the same ol c*** from the security naive.
About the flaw, it requires either physical access to the machine, or an ssh'ed login. It's hardly exploitable in the wild, unless someone were to craft a social engineering-type application that a really dumb user would fall for.
First, why would one have to be 'really dumb' to fall for a social-engineering type application? These are called 'trojans', and can be in any type of application (even something from a 'trusted' source). And as Windows has shown, there are a lot of dumb users out there, anyway (oh, right, if you're smart enough to use a mac, you'd never fall for this).
Second, please understand this affects ANY Cocoa app that runs as root. So it isn't a matter of fixing just ARDA, but fixing the security-hole in the framework or the communication. And, of course, fixing such things in 10.4 and possibly 10.3 as well.
Third, the continued argument that "need physical access" just points to how much Macs are just 'personal' computers and have made no inroads into businesses, schools, internet cafes, etc. Because if they did exist there, people would be A LOT more concerned over some user logging in to a shared computer as a 'restricted' user, running a program, and then installing all sorts of things, like key loggers, file scrubbers, etc.
But, hey, if the only macs you use are yours, and you're the only one who touches them, and you never run any software not produced by a 'trusted' source (and by trusted I mean basically large corporations) or where the program is Open-Sourced, and you've scanned the entire source tree to make sure someone didn't sneak in an exploit on this (it has happened in the past), then, yes, you can probably ignore this.
testudo
Fresh-Faced Recruit
Joined: Aug 2001
iHook is not vulnerable
08/06, 07:51pm reply
iHook is not vulnerable to any such attack. It's also not lab management software. See ihook.org.
fitter
Mac Enthusiast
Joined: Jan 2000