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

 



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

Origins of Mac OS X's runscript Security Hole 63

ahknight writes "codepoetry has an informative article about why there was a runscript command to begin with, where it came from, and how it's still used. A good read for people wondering why the command existed at all. Also, Daring Fireball has possibly the best solution so far with instructions on how to turn off the help and disk protocols entirely (much better than deleting random system components)." Update: 05/21 22:27 GMT by P :Daring Fireball also mentions an abuse of the telnet: handler that can overwrite any file you have write permissions to, and doesn't need a known path. There's also an applescript: handler, which I'd disable just for the heck of it, at this point ... Update: 05/21 22:36 GMT by P : Several readers note that Apple has just released Security Update 2004-05-24, which address the runscript problem, though apparently not the others.
This discussion has been archived. No new comments can be posted.

Origins of Mac OS X's runscript Security Hole

Comments Filter:
  • Does the understanding of the 'Help Script' security hole bring with it a correlation of opensource vs. closed source security issues?

    If the Help Script vulnerability was within closed source code, does it imply that OS X, with it's use of Apple closed source on top of FreeBSD, is less secure than other 100% open source OSes? Has a definative security comparison between Linux and OS X been done? (How about one for XP vs. OS X vs. Linux for that matter?)
    • by Llywelyn ( 531070 ) on Friday May 21, 2004 @05:40PM (#9221083) Homepage
      Nice fallacy.

      In short, no it doesn't.

      Open Source doesn't, by default, mean more secure any more than a published algorithm is more secure than an unpublished article, only that it has the *potential* to be more secure.

      There have been security holes from boneheaded design decisions made in various components of Linux before, a single security hole changes nothing nor tells us anything about the relative security of the two systems.
      • by 0x0d0a ( 568518 ) on Friday May 21, 2004 @06:11PM (#9221281) Journal
        Open Source doesn't, by default, mean more secure any more than a published algorithm is more secure than an unpublished article, only that it has the *potential* to be more secure.

        While you are technically correct, I believe that you are being misleading. I have the *potential* to be safer running in front of cars than staying on the sidewalk as well -- the issue that most people would be concerned about is what your chances are.

        I think that there are few cryptographers that would trust an unpublished algorithm -- many of us do not trust unpublished code.

        That doesn't mean that published code is automatically safe -- just that there are more grounds to trust it.

        I agree with you that this hole is not an open-source vs closed-source issue (the problem was in design, and enough of the design was available that someone who wanted to identify this could have done so), though I do think that decision decisions like this remind me more of desktop than traditional *IX developers.
    • by Anonymous Coward
      Why must every security hole in a non-OSS program turn into a OSS vs. non-OSS debate?

      The fact of the matter is that security holes can happen anywhere. It doesn't matter if the code in question is OSS or non-OSS. All that matters is that the problem gets fixed.

      And don't even start the "if it was OSS, we would have caught it earlier" argument. There have been plenty of holes in OSS that were not noticed for a long time.

    • I think that if "a definative security comparison" were possible, OS distributors would run them and then fix all the holes found. There's no way at this point to perform such thorough testing on systems so complex. Meaning no way to list all the things to test for, and no way to test them all before the technology is obsolete.

      If you disagree, you have found a very good career. (If only disagreeing with /. posts was always so fruitful.)
  • software update (Score:2, Informative)

    by Pathwalker ( 103 ) *
    Or, you could just run softwareupdate, and install patch SecUpd2004-05-24Pan-1.0 which, despite it's name, is out today and is described as:
    Security Update 2004-05-24 delivers a number of security enhancements and is recommended for all Macintosh users. This update includes the following components:

    HelpViewer
    • Re:software update (Score:5, Informative)

      by mst76 ( 629405 ) on Friday May 21, 2004 @07:21PM (#9221771)
      As already noted in the writeup and elsewhere in this thread, the Apple fix isn't enough. The other issues, discovered on the MacNN forum [macnn.com], are summarized here [unsanity.com].
      • Re:software update (Score:2, Informative)

        by monkeyneck ( 648963 )
        Other issues... I ran the Security Update, and then tried Unsanity's example. it didn't work. So, it looks like that particular vulnerability is fixed by the Security Update. The problem can be fixed with RCDefault [rubicode.com] quite easily, as well. Also, note that this vulnerability does not work from within the Opera 7.5 browser.
        • Other issues... I ran the Security Update, and then tried Unsanity's example. it didn't work.

          I also ran the Security Update from Apple, and then tried Unscanity's example. For me, it DID work. I've got a text file in my home directory to prove it...

          Are you sure the disk image downloaded quickly enough for the refresh to execute it?
          • Yes, I'm sure. I waited, and I tried it a couple of times. For the record, I have RCDefault installed, and I did set everything back to the default settings before trying Unsanity's example.
        • > Other issues... I ran the Security Update, and then tried Unsanity's example. it didn't work. So, it looks like that particular vulnerability is fixed by the Security Update.

          The issue is fixed by disabling Open Safe Files and the disk:// protocol, not by Apple's SU. There are rumors that other volume-mounting protocols are also succeptible to the attack (ftp://, afp://, smb://, webdav://, others?)
          • I hear what you're saying, and I have done this using RCDefault, which I used to set the disk protocols and others back to their default settings before doing the test. I've read the rumors, and have set my protocols accordingly. As I had set the protocols back to the defaults, anecdotal evidence in this case would seem to indicate that the Security Update fixed the problem. Either way, the idea that Paranoid Android is the ONLY fix is bogus.
  • Parnoid Android (Score:5, Informative)

    by Red_Winestain ( 243346 ) on Friday May 21, 2004 @05:32PM (#9221009)
    Paranoid Android [unsanity.com] protects against all of these potential exploits, including telnet://-nfoo.
    • Re:Parnoid Android (Score:2, Informative)

      by bw5353 ( 775333 )
      They also have a demo page, which unfortunately proves that Apple's latest security update (of 24 May, which is the day after tomorrow - sounds like a Bond film) is not enough (another Bond film).

      I tried their demo page after Apple's update and sure enough, a nasty text file was written to my home directory.

    • by karnat10 ( 607738 ) on Saturday May 22, 2004 @07:02AM (#9224195)

      Paranoid Android does not "protect" against anything, it just lets the user decide which URL schemes he wants to allow and which he doesn't, on a case by case basis. But not everyone is an IT professional and knows by heart which protocols are good and which are evil. My mom doesn't. So, is there a workaround that doesn't involve P.A.? I think so.

      I can see three different (but related) issues here:
      1. The "new and unknown URL scheme" issue exploited by malicious applications in downloaded and mounted disk images. Avoid this by not allowing disk images to be mounted automatically. You have to disable "Open Safe Files" (to avoid mounting disk images downloaded over http) and the disk: and disks: protocols. Having to mount all disk images by hand requires a decision from your side and gives you time to think about what you are doing.
      2. The "help://runscript" issue caused by the Help Viewer accepting arbitrary commands. Disable the help: protocol, who needs it anyway?
      3. The "telnet://-nfoo" issue caused by telnet's ability to overwrite existing files. Disable telnet:, ssh exists.
      Correct me if I'm wrong, but with those protocols disabled I can see no way for the malware to get its stinky little bits on my harddrive.

      To disable the protocols I used RCDefaultApp [rubicode.com] which is a neat (and missing) preference pane anyway.

      With the steps above taken and P.A. installed I opened the sample exploit [geekspiff.com] by the P.A. author (also linked from his white paper [unsanity.com] if you're paranoid which would seem normal under this circumstances). P.A. nicely asked me for permission, first for disk: and then for malware:. I granted both permissions, but since I had disabled the disk: protocol the image was never mounted and nothing happened.

      Now, installing an additional prefPane and disabling individual protocols is not exactly an easy one-click workaround for my mom, but it would be possible to guide her through the process on the phone, and after that she would leave me alone ... until the next flaw is found.

      But then again, I still have some hope in Apple releasing a Security Update which is more convincing than the one they just released. With flaws that serious, I expect a bit more than just the replacement of one application which is obviously only part of the problem.
  • by Dahan ( 130247 )
    Heh, check out the codepoetry [codepoetry.net] article in a browser that supports the <acronym> tag (such as Mozilla); all off the "NOW"s, such as in "NOW Help Viewer was almost 100% feature-equivalent to Apple Guide" and "NOW that the system had a real web display system..." have a tooltip that says, "National Organization for Women (Man-Haters)" :)
  • As discussed in this thread [macnn.com], the URL handling in OS X, plus the automatic app-registration, plus the auto-mounting of disk images makes for an easy execute-remote-code flaw in OS X. I quote the poster, smeger:
    In other words, lets' say I write a standard Mac app that deletes the home directory. The Info.plist for this app contains
    (snipped for lameness filter)
    <key>CFBundleURLSchemes</key>
    <array>
    <string>malware</string>
    </array>

    The malware author sticks this app into a DMG and uses the trick mentioned elsewhere in this thread to mount the DMG and then redirect the web page to "malware://anything". Boom - bye bye home directory.

    Am I missing something here, or did this vulnerability just get even nastier?

    yikes! Make sure you turn off "open safe files" in Safari (or the equivalent in your browser), and also disable the disk:// protocol, until this is resolved!

    • by mst76 ( 629405 ) on Friday May 21, 2004 @07:01PM (#9221649)
      The MacNN thread is a great read, you can witness the discovery of this vulnerability almost live. The new exploit means the malware author can make up his own protols like malware:// and give his app the appropriate creator code. Is other words, fixing the Help app is not enough, the problem is the automounting of .dmg and the URL handlers. Apple has been notified, so expect another fix soon.
    • Turning off 'Open safe files' in Safari is NOT enough!

      Disks can be automatically mounted through the 'disk://' URI handler. You should download RCDefaultApp and disable the handlers for 'disk', as well as 'ftp' and 'afp'. Oh, and 'telnet' as well, since that one is not safe too.

      At least until Apple comes up with a proper security patch.
  • The 10.2.8 update lists Help Viewer and Terminal updates...in the usual Apple verbose style.
  • Some notes (Score:5, Informative)

    by daveschroeder ( 516195 ) * on Friday May 21, 2004 @07:38PM (#9221875)
    Some notes about the now-fixed exploit:

    Some reports describe this as also a vulnerability with the 'disk' URI handler. This is incorrect. There is no vulnerability in the 'disk' URI handler; however, it could be used in conjunction with the 'help' vulnerability to deliver malicious content. On its own, 'disk://' does nothing more than enable the remote mounting of disk images. It was this capability combined with the 'help' vulnerability's ability to run arbitrary code at a known location that made it dangerous.

    Also, reports have also described this as a vulnerability in Safari, Internet Explorer, or other browsers. This is also incorrect. It was a vulnerability in the way Help Viewer handles 'help' URI requests passed to it by the OS.

    Last, there seems to be a misunderstanding that this vulnerability requires the OpnApp.scpt helper script within Help Viewer somehow. It does not. However, OpnApp.scpt, combined with the help URI handler vulnerability, could be used to execute some arbitrary commands. But "exploiting" it actually just comes back to general help URI handler vulnerability, now fixed.

    That said, this was a very serious exploit...probably the first major (potentially) easily exploitable vulnerability for Mac OS X.

    Incidentally, the people who removed Help Viewer altogether, or did things like chmod 000 (without setting it back) will be screwed and unable to properly install this update. Hopefully there's not too many of those people...

    Last, the telnet:// "vulnerability" isn't really a dangerous one, since it can only overwrite files (not directories) with a known name and path that you have permission to, and only one file at that. Yes, yes, plenty of preferences and maybe even some really irritating things like your iTunes Music Library database file. In any event, this definitely should also be fixed.
    • Re:Some notes (Score:5, Informative)

      by mst76 ( 629405 ) on Friday May 21, 2004 @07:48PM (#9221925)
      > Some notes about the now-fixed exploit:

      It's not clear from your writing if you realize that there is another similar exploit that has not been fixed yet. Malware writers can invent their own URL protocols and LaunchServices will automatically register them on mounted volumes (e.g. through disk://, and maybe also ftp:// and afp://). In other words, the same kind of exploit is possible without HelpViewer, for details, see this link [unsanity.com].
      • Umm... are you sure that all it needs is to exist on a mounted volume? Don't you have to execute the app in order to register the URL type with Launch Services?

        Is having the URL type in an info.plist enough?

        You can disable the disk: and disks: url handlers with the Default Apps prefs pane. I don't want to post a link to slashdot though. Use Google.

        I don't want Apple to disable the ability for apps to create their own protocols just because some malware some stupid user downloads might make use of it.

        • by Anonymous Coward
          The root issue is actually Apple's best usabilty feature -- the OS knows where programs are and what they can hadnle without an install routine or hardcoded paths.
          • by Anonymous Coward
            > The root issue is actually Apple's best usabilty feature -- the OS knows where programs are and what they can hadnle without an install routine or hardcoded paths.

            In other words, a classic Convenience versus Security issue.
            • I would rather put up up with the chance of having an exploit use this rather than putting up with complicated install routines and a central registry.

              There is no way to exploit this if you disable auto-mounting of disk images on download and the disk:/disks: protocols by with the default apps prefs pane.

              If Apple does release a patch to deal with this, I hope it only performs a check to see if the disk/disks protocols are called from the internet and provides a warning/confirmation dialog as the user if

    • Although I changed the permissions back to 755 via sudo before I applied the update, it really shouldn't matter because the updater is run as root. Root can read files/directories with permissions 000. Tested the problem after update and it fixes it. Those who rm'ed Help Viewer.app, however...
    • Re:Some notes (Score:1, Insightful)

      by Anonymous Coward
      > On its own, 'disk://' does nothing more than enable the remote mounting of disk images.

      The problem is that it does this without user notification and there is not easy way (without third party apps) to disable this.
      • Incidentally, the people who removed Help Viewer altogether, or did things like chmod 000 (without setting it back) will be screwed and unable to properly install this update. Hopefully there's not too many of those people...

      If you did the chmod fix, the download from software update will install -- but SU won't recognize that it has done so. That's what happened to me. Disk Utility's "Repair Permissions" fixed the changed permissions, and then all was back to normal.

  • Apple Download Page (Score:2, Informative)

    by SillyWilly ( 692755 )
    This update is available from the Apple website here [apple.com] for 10.3.3 and here [apple.com] for 10.2.8.
  • I posted this late to the earlier discussion about this hole, but chances are not many people saw it. Looks like I'm not the only one thinking this now though, so why not post it twice...

    It occurs to me that the help:// URI protocol problem could be broader than is generally being portrayed so far.

    Consider: the fundamental issue here is that an OSX web browser -- Safari in the original reports, but apparently also Mozilla etc -- is acting as a broker for any URI that the user may come across, delegating the request out to external handler programs. Whether those external programs handle their URIs safely may be an open question.

    The problem isn't really that Safari or Help is broken, but that the interaction between them, arising from the URI handling mechanism on OSX, is leading to Unintended Consequences.

    OSX can handle many different URI namespaces, some of which seem to be used nowhere other than OSX. I'm having a hard time finding an exhaustive list of the URI protocols that OSX supports, but a partial list [macosxhints.com] includes, in no particular order:

    http://
    https://
    ftp://
    mailto://
    ssh://
    telnet://
    aim://
    afp://
    nfs://
    smb://
    sherlock://
    itms://
    daap://
    help://

    So far, I can think of published vulnerabilities in the telnet:// and now help:// protocols [and this article expands on those points], but is that the end of it, or is the whole framework vulnerable to these sorts of attacks?

    I have a hunch that we're just seeing the thin edge of the wedge. If that's the case, then a real fix is going to hit a lot of the system, which in turn will mean that Apple is going to have a hell of a time doing proper bug testing on whatever fix they come up with. And if that is the case, then the patches we see for this through Software Update seem likely to be partial, possibly unreliable or ineffective, and may lead to system instability. (I'd hope that isn't the case, but if the fix has to be at some fundamental level of the UI then it can't be ruled out.)

    It may be that we don't see a true correction to this situation until at least the next 10.3 point release, if not 10.4...

  • by Anonymous Coward on Friday May 21, 2004 @10:00PM (#9222640)
    From Apple's own Security Announce mailing list [apple.com]:

    *snip*
    APPLE-SA-2004-05-21 Security Update 2004-05-24


    Security Update 2004-05-24 is now available and contains security enhancements for the following:

    HelpViewer: Fixes CAN-2004-0486 to ensure that HelpViewer will only process scripts that it initiated. Credit to lixlpixel for reporting this issue. This issue has been widely reported as a problem with the Safari web browser, but can affect other web browsers. This update will fix the issue for Safari and other web browsers.

    Terminal: Fixes CAN-2004-0485 to improve URL processing within Terminal. Credit to Reni Puls for reporting this issue.
    *snip*


    There was no disk:// hole (though it was used in conjunction with help://) and telnet:// is fixed as well... nothing else to see here... move along...
  • Today is the 21st. Does this mean that a company is actually thinking ahead in the security process?
  • KDE (Score:3, Interesting)

    by ensignyu ( 417022 ) on Friday May 21, 2004 @11:29PM (#9223061)
    There's an advisory [kde.org] listed on dot.kde.org that seems similar, although not as bad.
  • by RzUpAnmsCwrds ( 262647 ) on Saturday May 22, 2004 @12:00AM (#9223173)
    As much as I love to mock OS X, a similar exploit existed in Windows before SP1.

    Like OS X, Windows allows applications to create their own protocols. You can make an "irc://" protocol (and many applications do) or an "outlook:" protocol (as Outlook does) or many other protocols.

    The risk with OS X (and Windows) is that one of these protocols is registered to an application with a security flaw.

    Windows has had this technology since 1995; I don't know how long the functionality has been in Mac OS but from the looks of things it seems to be relatively new (perhaps it was introduced with OS X?). Apple has to get the bugs shaken out of the built-in applications. 3rd party applications also present a danger, but it is less (it is more difficult for an attack to work when it relies on a specific non-standard application).

    Internet Explorer (on the PC) has one of the most unique security models of any browser. IE has multiple security "zones"; it is possible to set the security settings for files on your intranet to be different from the security settings on the general internet (similar to having different users for different pages). Unfortunately, this also carries a risk: flaws in IE have lead to "cross zone" scripting which allows privelage elevation. IE SP2 a completely new zone system which is supposed to prevent this, but only time will tell if it is truly effective.
    • I don't know how long the functionality has been in Mac OS but from the looks of things it seems to be relatively new (perhaps it was introduced with OS X?).
      I recall using "hotline://" as early as MacOS 8.5 on my local http portal.

    • Apple Computer on Friday issued an update to Mac OS X to address flaws
      that security firms said could allow malicious code to be run on a Macintosh.

      From the sounds of this NEWS.COM release, it sounded as if Apple blocked the ability to execute future Windows emulators...

  • by saha ( 615847 ) on Saturday May 22, 2004 @02:32AM (#9223666)
    I feel this is a modest security threat because,
    http://bronosky.com/pub/AppleScript.htm [bronosky.com] Only runs "du" command.

    1) To have the maximum potential you need to be running as admin user, not standard user. I encourage everyone to be standard user when they run their computer. I also have a "-i" file in my home directory which forces a "rm" command to ask before deleting. This is an old unix trick to prevent one from deleting their whole directory by accident. Another method is to have "alias rm rm -i" in your .cshrc or .tchrc environment configuration.

    2) A malicious website would have to be catered specifically for Mac users and have them navigate to this website by clicking on the link. Most serious threats on the Windows side comes from you having your computer simply being plugged into the network. i.e. worms. I would classify this more under the realm of a Trojan Horse, which requires some trust on the users part.

    3) One can kill the unix terminal with in seconds of it launching. The script doesn't and can't surreptitiously launch in the background. You can actually see the script and terminal run in front of you.

    • by smcv ( 529383 )
      You assume that because the demo page can't do commands containing spaces, you're immune to commands containing spaces. Unfortunately, if an attacker can get a program of their choice placed at a location of their choice using an auto-mounted DMG file, they could write and compile, say, a shell script, or a C program which does the equivalent of "rm -rf /".

      That aside, further nitpicking:

      I also have a "-i" file in my home directory which forces a "rm" command to ask before deleting. This is an old unix tr
  • Switch (Score:2, Funny)

    See, you guys should just buy a Mac. We don't have this sort of problem.
  • by mattkime ( 8466 ) on Saturday May 22, 2004 @01:09PM (#9225612)
    that Little Snitch helps to prevent some of these exploits as well...

    http://www.obdev.at/products/littlesnitch/

    when i tried to run the example hack on the Paranoid Android site, Little Snitch warned me that I was trying to mount a remote disk image which i was able to cancel.
  • I don't know about anybody else, but none of my Macs can get to apple's patch servers today to get the HelpViewer patch. I had no trouble getting it yesterday on one of them, but today I get a timeout from three different T1s.

    Also, their main web site is pretty slow/hurtin. :-(

Truly simple systems... require infinite testing. -- Norman Augustine

Working...