Finally a Mac security hole

If you find this too hard to understand but still want to protect yourself, then you may find these simple installation instructions useful.

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
• MacNN
• slashdot
• unsanity.org
• macnews.de
• heise.de
• The Register

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.

Quoting Apple:

"The Finder automatically registers all applications as it becomes aware of them, such as [...] when the user navigates to a folder containing them."

Part of that registration involves LaunchServices (an under-the-hood thing, somewhat similar/related to InternetConfig) to check if a thusly found application advertises itself as being capable of handling a specific URL scheme. If the executable can do http for example, it will contain that information in such a way that Finder can access it (and pass the info on to LaunchServices).

Now if you've ever mounted a remote volume you will have noticed that when you do, Finder opens a new Finder Window showing the contents of the root of that volume. Sounds much like the situation in the quote above of "the user navigates to a folder", doesn't it?

Thus, when a volume containing an application on its root is mounted, the OS immediately knows what URL schemes it (claims) it can handle.

That's really nice. It means the user doesn't need to understand how to let the OS know that it just downloaded a new application and what it can do. The OS already knows 'automagically'. Now that I know this, I finally understand why Apple reportedly encourages developers to distribute applications on disk images: it enhances the user experience.

All of this is great. Nothing wrong with it as far as I can see. However, there is more enhanced user experience:

Since Mac OS X 10.2.x, some URL schemes are capable of mounting a remote disk image on the local machine. I'm not sure why I wasn't aware of this earlier. I sure as hell would have been as uncomfortable about it as I am with "Internet enabled disk images". (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.)

I assume the idea is that it is too complicated for (some) users to have to understand how to download a file, decompress it (and/or mount if it's an image) and place the resulting files he wants in the place he wants. I always thought the reason Apple encourages developers to distribute software through disk images was simply because of the analogy with shoving a disk in a 'puter: a somewhat easier concept to grasp than things like compression (.sit, .sea, .zip, etc.) or even encoding (.bin, .hqx, etc.). But clearly it was much more subtle than that.

So Apple made things even easier, by allowing several schemes to mount a remote disk image locally. The user initiates that (by clicking a link, or a button, whatever) and magically the file the user wanted appears (inside a newly opened Finder window showing the root of the mounted image). Now all he needs to do to 'install' is drag it to wherever he wants it. (The mounted volume can be ejected, or else will disappear on logout.)

Unfortunately, these 2 great features (yes they're great you Linux bozos, because they allow even grandma to finally be able to install something) lead to a serious vulnerability, waiting to be exploited:

Thus it is possible for an attacker to

1. Write a malicious application that says it can do some made-up URL scheme
2. slap it on a disk image
3. upload it to a server
4. distribute a URL pointing to the disk image, using any URL scheme that allows mounting of remote disk images
5. allow for a few seconds of time for the attacked Mac to mount that disk image and for the Finder to open it in a new Finder Window and for LaunchServices to then register what URL scheme the malicious program claims to be capable of
6. by using a META HTTP-EQUIV "Refresh" (optionally hidden inside a <FRAME>), he can then tell the browser to follow a URL that uses that scheme
7. the browser doesn't know the scheme, so passes it on to the OS (as it should). LaunchServices does know of it, and passes it on to the malicious program, which is launched and does whatever evil it is programmed to do

Make sure you understand this: it means 1 single 'click' on a URL, in any application, not just a Web browser, can set this chain of events in motion. And there's a hell of a good chance you will not even notice it. Because after that initial 'click' no further user action is needed and the only thing you might notice (assuming you can actually see your entire Desktop) is a Finder window opening showing the contents of the remote disk image. Even if you do notice that, by then you may have only a split second left to respond. You won't - according to research, it takes drivers several seconds before they respond (hit breaks, steer away) when something pops up in front of them unexpectedly. And a driver is (one might hope) in a much higher state of alertness than a computer user.

So it boils down to 1 wrong 'click' and you've been had :(

If you're lucky, the attacker lacks imagination and only deletes your home directory (that's assuming you're not logged in as an admin - else much more could be deleted and the entire OS could be rendered useless by this).

Yes, I say "if you're lucky", because in that case all you need to do is reinstall from back-up and you're fine again. You do make decent up to date back-ups of what matters to you, don't you?

If you're not so lucky, the attacker is more sophisticated.

Several proofs of concept have been published elsewhere, where you can see that Security Update 2004-05-24 does not protect against this attack:

• Unsanity's white paper offers 2 tests (one of them using ftp)
• The tests at ozwix.dk demonstrate the same attack, again through different URL schemes.
• Again the same attack, still more URL schemes (afp, ftp, disk, smb, nfs)

Both of these demonstrated I was still vulnerable in spite of having applied Security Update 2004-05-24 :(

I haven't managed yet to set up this exploit myself. I must have dropped a bit under my desk or something. So an attempt to explain how it works in detail would be no more than theory. Besides, all I want is inform people how to protect themselves, not help malicious programmers. So even when I do find that bit, I don't plan on explaining those details (and I urge others to keep equally quiet about it). Maybe after Apple has completely fixed this.

The only solution I feel comfortable to advise is to install Paranoid Android. Here's my rationale:

• Unlike some other solutions, the one ParanoidAndroid offers is non-destructive.
• ParanoidAndroid just protects from this attack, which makes it much simpler to install and use than LittleSnitch or RCDefaultApp, which requiere the user to understand much 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.
• ParanoidAndroid can be installed over the network. Nice for you admins out there who need to protect a couple of hundred Macs.
• With any of the other approaches, accidentally allowing mounting of a remote volume can be fatal. With ParanoidAndroid you will then still be warned when the attack uses a malicious scheme.

I can think of only 1 reason to not take the Paranoid Android approach: some people claim that APE, that which ParanoidAndroid is based on, causes instability for them. If that's the case for you, and/or you truly know what you're doing, one or a combination of the following approaches might offer protection:

• Use something like Little Snitch to block schemes that are capable of mounting remote disk images. If you don't bother to fully understand the exploit above and to RTFM of LittleSnitch, this will not help you.
• Use a Web browser that does not allow META HTTP-EQUIV "Refresh". I don't know of any that does (possibly lynx, or its cousin, links) and be aware that if someone manages to lure you into following a URL that uses a malicious scheme you'll still be fucked. No amount of technique can protect you from social engineering. Use your brain muscles.
• Use RCDefaultApp to disable every single scheme that can do mounting of remote disk images (this would render much of your Internet possibilities useless of course) or to point those schemes to known to be safe applications (like Fetch or InterArchy for ftp, etc.). Up to you to figure out which schemes can mount remote disk images and to make sure you don't miss one... But I most certainly do not plan to take on the responsibity of posting a list that might not be complete.

• Security Update 2004-06-07 fixes this by bringing up a dialog when a new application is about to be launched for the first time.
• John Gruber published an excellent article about why this hole isn't fixed yet and how Apple's inability to communicate hurts its customers.
• Mac OS X 10.3.4 fixes two other security issues:
  • A vulnerability in ssh
  • Mac OS X provides an option to ssh-encrypt afp sessions, but never actually did encrypt them. Mac OS X 10.3.4 deals with this (it appears that the 'regular'About' information on Apple's updates does not include changes concerning security, which are listed elsewhere), by putting up a warning dialog when you initiate such a connection, allowing you to Cancel or Continue. Apparently all previous versions of Mac OS X lead the user to believe the afp session is encrypted (in other words, this is probably broken still in Puma and Jaguar).
• Contrary to what Apple says, Mac OS X 10.3.4 does not include Security Update 2004-05-24. If you have only applied the 10.3.4 update, Software Update still lists Security Update 2004-05-24. Easy enough to still install, but it means that for those of us who tend to download and archive the Combo Updaters to have a quick route to install a fresh Mac OS X 10.3.4 we now need to be very alert not to forget to also apply Security Update 2004-05-24. (And install Paranoid Android ;))
• I have the impression that the quality of information streams elsewhere on the Net is slowly beginning to improve somewhat. This raises an interesting new issue: here and there people are offering good advice that differs from mine :) It's even turned into heavy debates here and there.

  For example, John Gruber explains why he prefers using RCDefaultApp for prevention, and what he dislikes about Paranoid Android. Fine. I'll let you in on a little secret: that's exactly what I did on my Macs.

  So why do I so strongly advice people use Paranoid Android? Because I am not my target audience. I'm not publishing this site to inform me.

  I'm all for people expressing their opinions and sharing views and discussing that (you can find me on Usenet). But that makes sense only in bi-directional communication. The Web is not bi-directional (braindead concepts like Web forums exempted). The Web is like TV: there is a lot to be consumed and zero interaction. I am publishing my story here. You cannot respond, at least not on the same stage (this site).

  So when I choose to publish something on the Web, I don't do that just to inform others of what is my personal solution to a general problem. I do it because I have a target audience in mind. In the case of this page, the target audience is largely those of you who are not programmers, but just regular Mac users who don't know much about how that pretty box actually works on the inside. I saw how hard a time some developers, me included, were having to grasp the URL scheme/LaunchServices security hole. And I saw that for you 'regular' users it was even much harder. You are my target audience. So the advice here is my advice to you. (In fact, as you may have noticed, I have by now added another target audience. If only to help you help your friends/family.)

  If I would advice you to get RCDefaultApp, install it (how?), configure it (how?), I would be confusing half of you, which would result in half of you not protecting yourself well. LittleSnitch requieres even more understanding. (Remember, when I set up this page there was no source whatsoever explaining the issue at hand (except for 2 german Web sites that I found later - If you want to prepare for future events, I would advice you to learn german ;)). The info was out there, but it would have taken take you a lot of time to find, and then you still needed to have enough background information about the system in general in order to recognize what exactly you had just found.) In practice, many of you would never have found the essential information.

  Well, there you have it. This is why I strongly advice you all to use Paranoid Android and only sideways suggest LittleSnitch and/or RCDefaultApp (or MisFox, or MoreInternet, and there's even more).

  Lesson learned: when you read something, consider who the author is targeting. It may not be you.

  Btw, I do disagree with John and others' complaint about Paranoid Android on one point: if what APE does really is that bad (it may be, I don't know - I've never had a problem with it and I've used it for 1 or 2 years) then they should complain to Apple for it being even possible in the first place.

• TidBITS today published 2 good articles on this. Essentially the same story as here, but if you're having trouble understanding my explanation, it's always good to hear the same thing explained in different words by someone else. Adam Engst explains how the exploit works (but, possibly due to the confusion surrounding the earlier reports, mistakenly claims that this has something to do with AppleScript - not true: any programming language can be used to write a malicious program that exploits this security hole), and Matt Neuburg explains how Mac OS X's inner-workings' design made all this possible in the first place. (Note that where Matt says "Safari" you should read "Web browser", or you might think all this is a Safari issue - it is not.)
• Some of you have already put 2 and 2 together, but since most of you haven't I feel the need to warn that not taking any of the suggested protective actions is a serious mistake. Too many people have already pointed out and even demonstrated how this security hole could be exploited by using even more (very well-known) tricks, ranging from social engineering to (very easy) purely technical ones. (I'm not going to spell them out right now. Unless that information starts to spread elsewhere anyway, or an actual attack takes place, I plan to wait with that (including a screenshot that will probably shock some of you) until Apple has fixed this. This essentially means that not one single URL can be trusted to not point to an attack. In other words: if you have not applied the necessary security measures every link you 'click', in every program, contains a potential risk. Even if that link points to a well known Web site that you have reason to trust. (Not that I am aware of any actual such attack at this moment. The Mac community has shown great maturity thus far.)
• According to http://ozwix.dk/OpnAppFixer/testit.html, as demonstrated there, ParanoidAndroid1.1 does not work if you don't also have either ShapeShifter or RealOne Player installed. Ugrade to Paranoid Android 1.2.
• A big thank you to all of of you who bothered to provide decent information, be it through mailing lists, newsgroups, Web forums, or through private email (sorry I didn't respond to all of you individually - if I had done so I wouldn't have had any time to publish this). Yes, it was (and still is ;)) a huge task to separate the good from the bad info, but in the end that was all I did here. The actual information came from you. Some of you even bothered to explain things I did not understand.
  Although I do not approve of publishing a security hole when you find it (first report to Apple and allow them a reasonable amount of time to fix it), so much of this had become public already that it was up for grabs for malicious crackers, yet unavailable to potential victims. You did the Mac community a huge favour by trying to inform them so they at least have a chance to defend themselves aginst this exploit.
• For you wannabe-journalists out there: all this is an explanation of a possible exploit that AFAIK is not actually used 'in the wild'. There are proofs of concept out there. If you don't understand what that is, look it up before opening your mouth about this! Hint: it is not a trojan nor a virus.
• This exploit should work in any browser. A Mac browser is supposed to pass schemes it cannot handle on to the system. Any browser that doesn't is broken.
• The story that disabling Safari's "Open 'safe' files after downloading" option will protect you is garbage. It is wise to switch that option off, but those who claim that that will protect you from the above described attack haven't understood a damn thing and are doing their fellow Mac users a gross disservice.
• All the fixes that disable Help Viewer's runscript capability have been superceded by Apple's Security Update 2004-05-24.
• There just happens to also be a (much less dangerous) telnet exploit which has nothing to do with all of this. 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

This was one of the very first comments on Slashdot:

I've got to hand it to Apple...
"help:runscript=..."
No double-decode, unicode obfuscation, or CMD.EXE parms. Even the exploits are user-friendly!

:)