It’s not a Trojan horse, but a recently revealed security vulnerability does appear to be a very real concern. The exploit relies on unsafe actions that Apple allows for certain URL schemes (such as the http, ftp, or mailto bit at the beginning of a URL) and makes it possible for a malicious code to be delivered and executed silently, without the user realizing anything has happened.
The problem was initially thought to revolve around only two of these URL schemes: disk and help. When you combine the capability to download and automatically mount a disk image (which could contain a malicious AppleScript script) and the capability to run that AppleScript (because it’s in a known location) via Help Viewer, you end up with a recipe for trouble. Turning off Safari’s Open "Safe" Files After Downloading option in its General preference pane isn’t sufficient protection (and the vulnerability is even present if you use some other Web browsers).
Apple responded within days, issuing Security Update 2004-05-24. Although Apple’s description was terse, as always, it appears that the security update installs a new version of Help Viewer that presumably eliminates that program’s capability to execute AppleScripts sent via help URLs. (The security update also included a fix to URL processing within Terminal for users of Mac OS X 10.2 Jaguar; again, Apple provided no details.)
Unfortunately for everyone involved, Apple’s fix was merely a band-aid on what now seems like a much more involved and deep-seated problem, which I’ll let Matt Neuburg explain separately elsewhere in this issue. Suffice to say, the concern over Help Viewer was merely a special case of the overall vulnerability, which revolves around an attacker being able to post a disk image containing a malicious application that registers a special URL scheme. When a user clicks the link (which would of course be obscured to look like something else), the disk image is downloaded, mounted, and the special URL scheme is registered with Mac OS X. The server providing the URL waits a short while (until the disk image is mounted and URL scheme registered) and then automatically redirects the user to another URL that uses the just-registered scheme. That subsequent URL tells Mac OS X to launch the malicious application. To quote from Maurice Sendak, "’And now,’ cried Max, ‘let the wild rumpus start!’" Kudos to TidBITS Talk reader Sander Tekelenburg for a coherent page explaining this process.
Without in any way detracting from the serious nature of this vulnerability, it’s important to clarify a few things. This is not a Trojan horse, it’s not a virus, and although several people have posted proofs-of-concept, I’m not aware of any reports of any actual malicious software that uses this technique.
I’m certain Apple is working furiously to come up with a fix; until they do, the best advice for normal users (other than to keep good backups!) seems to be to download and install Paranoid Android, a free utility developed by Unsanity. Once installed, Paranoid Android watches for unknown URL schemes and displays a warning dialog that lets you cancel the action before your Mac can be compromised. Unsanity and Jason Harris deserve significant credit for developing Paranoid Android and releasing it for free. To learn a bit more about how Paranoid Android works, read Jason’s white paper at the second link below.
Some people are bothered by the technique Paranoid Android (like Unsanity’s other Haxies) uses; my take is that you can either follow John Gruber’s advice on his Daring Fireball for eliminating the need for Paranoid Android or consider it a temporary solution until Apple releases a fix. John recommends using Rubicode’s RCDefaultApp utility to disable potentially dangerous default URL handlers. Others have also recommended using Objective Development’s Little Snitch to alert you to potentially harmful network behavior.
It’s worth keeping in mind that any action you take with your computer is potentially unsafe; a bug in a totally legitimate program could cause as much havoc as malicious software. Although there’s no reason to become entirely paranoid, we recommend that you exercise reasonable caution when evaluating the sources of files you download and links you click. And the most important thing to remember is that regular backups that maintain multiple versions of changed files will help you recover from almost any disaster with minimal effort.
Lastly, although Apple is undoubtedly aware of the seriousness of the situation, it’s still a test by fire. After a somewhat rocky start, Apple’s security group seems to have done a good job of dealing with the relatively minor exploits so far, most of which revolved around the Unix tools bundled with Mac OS X. This, however, is a new thing, a Mac OS X-specific vulnerability that exists purely because of Apple’s design decisions. More concerning is that it wasn’t discovered inside Apple and fixed before anyone had a chance to discover it. That implies that Apple’s security group may be more reactive than proactive; I would have hoped that at least part of the job description of the security team would be to probe constantly at Mac OS X and Apple’s bundled applications for potential vulnerabilities.