Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Bug Businesses OS X Operating Systems Apple

Mac OS X Root Escalation Through AppleScript 359

Posted by timothy 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.
This discussion has been archived. No new comments can be posted.

Mac OS X Root Escalation Through AppleScript More

Mac OS X Root Escalation Through AppleScript

Comments Filter:

  • ARDAgent is Apple Remote Desktop (Score:5, Informative)

    by dch24 ( 904899 ) on Wednesday June 18, 2008 @03:44PM (#23844951) Journal
    ARD = Apple Remote Desktop You can remove it by following these instructions [macosxhints.com].

  • Physical access? (Score:3, Insightful)

    by Menkhaf ( 627996 ) on Wednesday June 18, 2008 @03:45PM (#23844973)
    Could somebody explain how running a script requires physical access?

    • Re:Physical access? (Score:5, Informative)

      by pudge ( 3605 ) * Works for Slashdot <<slashdot> <at> <pudge.net>> on Wednesday June 18, 2008 @03:59PM (#23845239) Homepage Journal
      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.

    • Even better question (Score:3, Insightful)

      by Moraelin ( 679338 )
      My even better question is: why is "bah, it requires physical access" seen as an automatic "don't worry about it" around these parts?

      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.

      • Re:Even better question (Score:4, Insightful)

        by TrekkieGod ( 627867 ) on Thursday June 19, 2008 @01:00PM (#23861167) Homepage Journal

        My even better question is: why is "bah, it requires physical access" seen as an automatic "don't worry about it" around these parts?...Workstations at work have lots of people who can log into them...Plus there are a lot of people who can physically get near any computer, up to CEO level. Like, say, the janitors.

        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.

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

    by jeffmeden ( 135043 ) on Wednesday June 18, 2008 @03:48PM (#23845037) Homepage Journal

    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.
    • 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.
      • 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: (Score:3, Insightful)

          by argent ( 18001 )
          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 co

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

        by Applekid ( 993327 ) on Wednesday June 18, 2008 @04:42PM (#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: (Score:3, Funny)

        by smitty97 ( 995791 )

        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: (Score:2)

          by argent ( 18001 )
          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? (Score:4, Insightful)

      by Goaway ( 82658 ) on Wednesday June 18, 2008 @04:22PM (#23845647) Homepage

      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.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Wednesday June 18, 2008 @03:53PM (#23845113)
    Comment removed based on user account deletion

    • Re: (Score:2)

      by pudge ( 3605 ) * Works for Slashdot

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

      by Colonel Fahlt ( 1267662 )
      (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?)

    • Re: (Score:2)

      by Lars T. ( 470328 )

      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.

  • 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: (Score:3, Insightful)

      by Medieval_Gnome ( 250212 )
      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? (Score:4, Insightful)

      by Anonymous Coward on Wednesday June 18, 2008 @04:01PM (#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: (Score:3, Interesting)

      by MyDixieWrecked ( 548719 )
      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 s

      • Re:Physical access? (Score:5, Interesting)

        by MyDixieWrecked ( 548719 ) on Wednesday June 18, 2008 @04:12PM (#23845465) Homepage Journal
        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: (Score:2)

        by Henriok ( 6762 )
        I got this exact result to. 10.5.3/Intel, ARD activated.
  • 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 execu

    • Re:not a full exploit, yet (Score:5, Informative)

      by rritterson ( 588983 ) on Wednesday June 18, 2008 @04:12PM (#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: (Score:2)

        by rthille ( 8526 )
        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^Hcoffee-makers?

  • Proof of Concept Possibilities (Score:5, Insightful)

    by AgentOJ ( 320270 ) on Wednesday June 18, 2008 @04:44PM (#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.

  • The exploits - they do nothing! (Score:3, Informative)

    by Lars T. ( 470328 ) <Lars.TraegerNO@SPAMgooglemail.com> on Wednesday June 18, 2008 @05:40PM (#23846711) Journal
    After about 20 seconds waiting:
    23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
    I'm so not impressed.

  • Intellectual Honesty (Score:5, Interesting)

    by JeffSpudrinski ( 1310127 ) on Wednesday June 18, 2008 @05:41PM (#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.
  • 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
  • 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 s
  • use the 'password reset' utility on the install disk,

  • Nope, not here (Score:2, Informative)

    by clang_jangle ( 975789 ) *
    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? :)

  • 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)

    by TheNetAvenger ( 624455 ) on Wednesday June 18, 2008 @07:39PM (#23848203)
    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?

  • Apple's Knowledge Base reports this is 'safe' (Score:5, Informative)

    by AEton ( 654737 ) on Wednesday June 18, 2008 @09:22PM (#23849363)
    Item TS1448 [apple.com] in the Apple support knowledge base addresses this issue and is dated June 6, 2008. The issue was reported by users as early as October [macrumors.com].

    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 resolution:
    You can safely ignore these messages. They are accurate but not a cause for concern.

    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'm a Mac. And I'm a PC (Score:5, Funny)

    by patio11 ( 857072 ) on Wednesday June 18, 2008 @11:50PM (#23850665)
    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.

  • Fix using Info.plist (Score:5, Informative)

    by jediknil ( 1090345 ) on Thursday June 19, 2008 @01:07AM (#23851171) Homepage

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

    <key>NSAppleScriptEnabled</key>
    <string>YES</string>

    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.

Slashdot Top Deals

news: gotcha

Close