For those of you who feel that security through obscurity is a good idea: I disagree. One reason I disagree is that at the moment of this writing there is a huge buzz about this security hole, but it is totally unclear how users can protect themselves against it. Much of the advise given (and even some proof of concepts) is just plain wrong and will only give those who follow it a false sense of security - much worse than no security but knowing it. Even worse, scared people can easily be lured into downloading an actual trojan advertising itself as a protective solution! Most of the main Mac press sites seem to just copy each other's crap without checking facts. (I suggest that, once you've read this page and understand the issue, you go back to those sources and see what they reported right and what they reported wrong. It doesn't hurt to know how much trust to put into which source the next time something is up...)

I could say "do this to protect yourself", but by leaving out an explanation I'd just be adding to the FUD. By explaining how this security exploit works people can understand how something would in fact protect them.

In any case, all that's here I found on the Net. All I did was separate the FUD from the good info. Sources I used, both the good and the bad:

• MacFixit
• Secunia.com
• www.insecure.ws
• <news:nl.comp.sys.mac>
• <news:comp.sys.mac.system>
• Macintouch
• Wired
• MacOSXhints.com

One reason I bothered was the recent FUD about first Intego's "first Mac OS X trojan" (an executable disguised as a MP3 - whether it was a trojan or only a proof of concept is not clear), and right after that the FUD about MacWorld UK's "first/second Mac OS X trojan" (an AppleScript applet with an M$Office icon slapped on it, posing as M$Office installer... duh).

Then a week or so later this one turned up. I felt it was time to publish some actual information. I had seen too much FUD.

Being a professional AppleScripter I was also quite annoyed by all the totally unfounded fear of AppleScript that these zero-quality reports generated.

Sometime around the afternoon of Tuesday, May 18, 2004, I started coming across several reports about a supposed security hole in Mac OS X 10.3, or in Safari, or in Help Viewer, or in Mac OS X's disk:// URL scheme... Vagueness ruled. All of them screamed that a huge security hole was found, none of them explained the issue, all of them gave extremely vague instructions on how to protect yourself against this exploit. Including posting a script that couldn't possibly work as advertised.

Knowing that Mac OS' Help Viewer's help:runscript (which allows for clicking a hyperlink in a (HTML based) help page to have a local AppleScript script triggered) has existed for many years, predating Mac OS X, and that it can only run local scripts and that the remote Web page needs to provide the full path to the script, I couldn't see what the risk might possibly be. So I publicly showed scepticism. Luckily, a few people turned up who actually did know what they were talking about. Then it became clear that by combining help:runscript with several other techniques, there indeed is a security hole.

Since some incarnation of Mac OS X it handles a disk:// URL scheme (as used in the proof of concept below). To me, this seems to be the problem - the disk:// protocol not just fetches a ".dmg", it also mounts it! I'm not sure why I wasn't aware of this earlier. I sure as hell would have been uncomfortable about it. (I had never run into such a URL before and am not aware of Apple having advertised it. So far I haven't been able to find documentation on it.)

Thus an attacker can lure a victim into following a disk:// URL and then a help:runscript URL pointing to a malicious script on the by then locally mounted image.

The only reason the disk image is involved is that it allows for the attacker to know the full path to the malicious script (assuming the admin of the Mac hasn't changed the default mount point - I doubt many people have). The disk image serves no other purpose.

Extra sneakiness is possible if the victim's Web browser allows <FRAMES> and especially a META HTTP-EQUIV "Refresh" (most popular Web browsers do). The first may contain code that has the browser download the disk image (using a small frame, which most Web browser won't even show) so the user still thinks he's just looking at a page, unaware he downloaded something. The latter allows for some time to download the disk image and mount it, then refreshes the 'hidden' frame by loading the help:runscript URL pointing to the script on the now mounted disk image.

Proof of concept for that approach can be found elsewhere.

To keep the steps involved clear, I did not include the <FRAMES> or META HTTP-EQUIV "Refresh" approaches in this proof of concept. They are well-known enough anyway to be understood.

All the script in this proof of concept does is grab your short username and show you a dialog. Still, that's just my word. It's up to you to trust this page or not. (If you're smart, you don't trust me. Instead you use http to fetch the disk image I link to below, then mount it and use Script Editor to read the source code of the AppleScript that's on it. That way you know what will happen. No need for trust.)

1. Mount a disk image
2. Run the script residing on that disk image.

Note: the only reason the disk image is 200KB is that hdiutil doesn't seem to let you create something inbetween 100 and 200KB :) The script itself is only 60KB so a 110KB disk image (allowing for a little overhead of the images itself) would have more than sufficed. The smaller the image, the faster it can all happen...

Some different approaches on how to protect yourself, in the order that I feel is most sensible:

1. Of all the ad-hoc solutions being offered Paranoid Android seems to me the only one (besides Little Snitch) that takes the right approach. Reasons why I now list it (just) above Little Snitch:
   • Unlike other solutions, the one ParanoidAndroid (and LittleSnitch and iCab) offers is non-destructive. (The solutions that break Help Viewer might lead to problems the next time you run a system update and Installer.app runs into unexpected situations.)
   • ParanoidAndroid just protects from this attack, which makes it much simpler to install and use than LittleSnitch, which requieres the user to understand more of what he's doing.
   • ParanoidAndroid is free, which makes it more likely that people will install it.
   • ParanoidAndroid can be installed and activated for all users on a machine with just one action (the installer's option to "install for all users"). Whereas with LittleSnitch you need to configure it for each user.
   • ParanoidAndroid also protects from this telnet attack. That attack is much less nasty, but still it's nice to be protected from it.
   • ParanoidAndroid is from a well-known and decent Mac software house, making it extremely unlikely to be a sloppy hack (like so many of the other 'solutions' out there), let alone a trojan.
2. Use something like Little Snitch to disallow the program diskimages-helper to fetch & mount disk images. This essentially disables the disk:// protocol. People who know what they're doing may like this better than ParanoidAndroid, because LittleSnitch offers much more control. But because some people who think they know what they're doing don't, I'll spell it out: you will still need to disable Safari's "Open 'safe' files" option if LittleSnitch is the only protection you use!
3. It appears that iCab is immune. A lIkely explanation seems to be that iCab has its own internal help: protocol and therefore does not pass the help: URL on to the system. Thanks to Smokey Ardisson and Arne Johannessen for pointing this out.
   Note that only the author of iCab can say for sure if this will still be the case in future versions.
4. Use a tool like RCDefaultApp (because Apple decided you don't need no stinking interface to InternetConfig since Panther:() to have the help: protocol point to some other application than Help Viewer. Don't point to another Web browser, but to something that will not pass on the help: scheme to the OS. I suggest Chess.app. Of course this means some of Help Viewer's capabilities will not be available anymore - that's exactly the idea. Be warned that I orginally did this with MisFox and then when I tried to have it point to Help Viewer again that didn't work anymore. I don't know why, but I was able to get it working again with RCDefaultApp, possibly thanks to it knowing what the OS considers to be the defaults. That's why I now advice RCDefaultApp instead of MixFox :)
5. Similarly it may be possible to use RCDefaultApp to have disk:// URLs point to another program than diskimages-helper. I haven't tried, however several others else told me they did exactly this and it worked:
   use RCDefaultApp to create a new entry for the disk protocol and point that to something useless (well, for this ;)) like Chess.app. To undo this, point the disk protocol to /System/Library/CoreServices/DiskImageMounter.app (assuming Panther - It appears to be something else in Jaguar, which I don't have available).
6. For those of you out there who know what they're doing, you could try running this in Terminal.app: sudo defaults write /System/Library/CoreServices/Help\ Viewer.app/Contents/Info NSAppleScriptEnabled -bool 'no'. To revert, use sudo defaults write /System/Library/CoreServices/Help\ Viewer.app/Contents/Info NSAppleScriptEnabled -bool 'yes'. (Note that on my system this changed the permissions of that file from 644 to 600. Make sure to check yours.) One reason I'm not confident this is 100% effective, is that if you have another copy of Help Viewer on a mounted disk somewhere, the OS may find and use that one instead. The same, applies to this next one:
7. Delete Help Viewer. (Keep a copy around, compressed, or on a CD, in case you ever do need it. Good chance it needs to be in place (or will be reinstalled) when you install a system update!)

• For you wannabe-journalists out there: this is just a proof of concept and AFAIK this exploit is not actually used 'in the wild'. What is on this Web page is not a trojan nor a virus.
• {Sigh} Even more crap today at MacFixit where an Opera developer is quoted (from Message-ID: <opr789tax6icz8n2@news.opera.com> in <news:opera.mac>)

  MacOpera doesn't support the Mac 'help:' scheme. It might be possible to enable it (if you dare) from 'Preferences > Programs and paths'. There is a reason why Opera (on any platform) doesn't enable by deafult passing random strings to the operating system for any registered scheme like 'irc:' or 'rtsp:' or 'edk:' or 'mms:' etc."

  Well, I can tell you that on my machine Opera is vulnerable. Both Opera 5 and 6.0.2. Not Opera 7.5, no. And no, none of this is about passing random strings. It's about standard Mac OS behaviour that applications are expected to adhere to. (I consider the fact that iCab is immune a bug with a lucky side effect. A decent Mac app passes the help URL on to the system. It's up to the system to make sure nothing nasty can happen.)
• Safari has almost nothing to do with this. The above proof of concept works for me with Safari (1.2.1), as well as Mozilla (1.5.1), Opera 5.0 & 6.0.2 and InternetExplorer 5.2.3. It does not in iCab 2.9.8 and Opera 7.5 (all under Mac OS X 10.3.3). I see no reason to bother to test more browsers. A Mac browser is supposed to pass schemes it cannot handle on to the system. Any browser that doesn't is broken.
• The rumour that disabling Safari's "Open 'safe' files after downloading" option will protect you is nonsense. Just disable that option and try the above proof of concept if you want to see with your own eyes.
• The proof of concept posted at http://bronosky.com/pub/AppleScript.htm is misleading, as is evident from what people say about it. It does not tell Terminal.app to run a command. What it does is open a file. The file in question happens to be a cli executable, so the OS opens it in Terminal.app. This also explains why the author of that page says he hasn't been able to execute a command with arguments (like his "ls -la" example). Nothing to do with the spaces he blames it on, but with the fact that with this exploit you are not sending commands at all - you 'only' ask the OS to open a file. If the file happens to be an executable, it launches. It's no different than double-clicking something in the Finder.
• Some people suggest a fix by improving the code of the OpnApp.scpt which is used for this exploit. I'm sceptical about that, because there are likely several copies of it on each system. sudo find / -name OpnApp.scpt | grep "OpnApp.scpt" lists 314 on mine. Besides, you may be putting new copies in place without being aware of it (by instaling something or copying it from another disk). And then there is the (albeit minor I think) risk that making changes to such files may be something Installer.app does not anticipate, so next time you run an update it may give problems. This is the reasn I do not list Don't go there GURLfriend as a solution.
• Rumours that a variant attack does not need the help: scheme appear to refer to a (much less dangerous) telnet exploit. The only way in which it is related to 'our' security hole is that I think that this is not simply an Opera bug, because another browser that does not handle telnet:// URLs will simply hand it off to the system, which in turn will pass it on to whatever happens to be the default telnet client on your Mac. If that telnet client (which might be Opera, if you have it configured as your default telnet client) happens to be vulnerable, the attack succeeds, even if you were using another Web browser to begin with. Paranoid Android protects against this one too.
• I have no ties with the authors of ParanoidAndroid, Little Snitch, or RCDefaultApp