Journal: News & Comment

Apple's Mac OS X security alert in plain English

Permalinks to this entry: individual page or in monthly context. For more material from my journal, visit my home page or the archive.

Or, can a hacker erase my Mac's hard disk from a web page?

NOTE: I have edited this post several times since its original appearance to try to keep it up to date. You can certainly go into a lot more details elsewhere. Many gory details are available, John Gruber has made further excellent analyses (on May 23 and 24), and I've updated the steps below accordingly.

There are also fairly long, but excellent and plainly written, explanations of the problem and what to do at TidBITS. I'm hoping Apple issues additional patches that make all the extra steps unnecessary. Now, back to the story.

At a meeting I attended this week, the speaker warned users of Apple's Mac OS X version 10.3 ("Panther") operating system that there was "an AppleScript on their computers that could erase their hard disks." He wasn't completely wrong, but what he said was misleading, and (well, perhaps) needlessly alarming.

It is true that this week revealed the first serious potential security vulnerability in Mac OS X (previous false alarms notwithstanding). Many of the online news items and advice on the matter have been good, but they're also often confusing, and I hope I can post something clear and accurate here for those without the technical background needed for some of the material written elsewhere.

The basics: what is a "URI handler?"

Most of the time, when you visit a web page, the address that appears at the top of your browser window begins with https: (standing for Hypertext Transport Protocol)—the "language" your computer uses to communicate over the Internet with the computers that send the web page you're viewing.

The whole web address (such as https://www.penmachine.com/) is known as a URL (Uniform Resource Locator) or URI (Uniform Resource Indicator)—never mind the arguments about the distinction between the two. Web browsers use the https: or https: prefix to figure out what language to use for communications—https:, for instance, is the same as https:, but mathematically encrypted for extra security. There are other options, including ftp: for File Transfer Protcol, file: for opening a file on your local hard disk, and so on.

Mac OS X can assign different programs to handle different URI prefixes—those programs are the operating system's assigned URI handlers. Usually, your default web browser (Safari, for instance) handles https: and https:, but with a bit of work you could theoretically have Safari handle https: and Internet Explorer https:, so if you clicked on a secure URI in an e-mail message, Internet Explorer would launch instead of Safari. Few people bother, though, and most of us leave the settings as Apple sets them.

So what's the problem?

Mac OS X has a whole bunch of URI handlers set up, most of which you never see in your web browser. People recently discovered that some of them weren't entirely safe. That is, the way they are configured by default on a Mac system means that someone could theoretically set up a website that did something nefarious, such as sending a program to your computer and then running it. That program could (again, in theory) do something really nasty, such as trying to erase all the files in your Home folder, including all your documents.

The key thing is that no one has actually done anything like that, even though it is possible. The protocol prefixes concerned are not the common ones, but rather these more obscure variants:

• help: (assigned to the Help Viewer application)
• disk: and disks: (for automatic mounting of downloaded disk image files)
• telnet: (for remote Unix-style command-line access)
• afp: (for automatic mounting of AppleShare servers)
• ftp: (but only when assigned to the Mac OS X Finder)

According to the latest updates, if I were a determined bad guy, I could even make your Mac accept a brand new protocol (I could call it penmachine:) and do something ugly.

The regular https: and https: protocols are just fine, and you don't need to worry about them. However, it is not just the Safari web browser or Mac OS X 10.3 ("Panther") that are affected. As far as I can tell, older versions of Mac OS X and other browsers are at least partially vulnerable too. Mac OS 9 and earlier use a different architecture, and are safe from this problem.

Okay, what do I do?

The solutions are pretty simple, but require downloading a separate program or two for full protection from the vulnerability. There are four major steps (I originally wrote three, but one more turned up, and then I changed the last one later on), in order of easiness. You can do the first one, or two, or three, but for the best defense, do all four:

1. Use Software Update to download and install the latest May 24 Apple Security Update (for 10.3 Panther or 10.2 Jaguar), which prevents Help Viewer from doing anything unauthorized with the help: protocol:
   1. Click the Apple Menu on the left side of your menu bar.
   2. Choose System Preferences from the menu.
   3. When System Preferences opens, click the Software Update icon.
   4. Choose Update Now. You'll need to restart once you've followed the instructions.
   
   
2. Prevent Safari from executing downloaded files automatically (if you use it):
   1. Open Safari.
   2. From the Safari menu, just to the right of the Apple menu, choose Preferences.
   3. In the Preferences window, find the Open 'safe' files after download checkbox.
   4. Clear (uncheck) the Open 'safe' files after download checkbox, then close the Preferences window.
   
   
3. Follow the instructions on John Gruber's web page, where he tells you how to download and use a handy program called RCDefaultApp to disable the disk:, disks:, telnet:, and afp: URI handlers. See below for what to do about the ftp: handler.
   
   
4. Reassign the ftp: protocol to an actual FTP program (such as Transmit, my favourite), or even to your web browser, rather than to the Finder.

That should cover it. Again, so far no one has exploited this vulnerability, and if you follow the steps above, no one should able to on your machine anyway.

John Gruber writes that my original fourth recommendation is unnecessary: "I cannot recommend the use of [the] Paranoid Android [monitoring application]. As far as I have determined [...] every vulnerability handled by Paranoid Android can also be solved by changing or disabling Mac OS X's default URI handlers."

Thanks to Alex Caro for the info on step 4.

 |