Subscribe to
Posts
Comments
NSLog(); Header Image

Mac OS X URI Handlers

Suppose someone harboring a grudge over the fact that .Mac now cost $99 instead of being free created a cool shareware game. This game was cool enough that Apple brokered a deal to give away a free copy to .Mac subscribers.

People download the special, pre-registered copy of the game en masse.

A few weeks later an "update" is released and customers are directed to the company's website. Once there, a hidden frameset tells the application to launch via the "evilgame:" protocol. This URI protocol handler is only present in the special version available to .Mac users.

The application launches, takes the input (evilgame://dotmacsucks perhaps?), and proceeds to do its dirty work: cleaning out your iDisk. You notice that the game has launched. "Maybe it's updating itself" you think. A phony "updating application" progress bar could seal the deal. You don't even notice your iDisk content disappearing! Truly sneaky developers, in fact, could include a smaller application bundle inside the main bundle which has no UI.

Though the above is unlikely to happen, the point here is that it could. It could happen with any application released into the wild - the above scenario involving .Mac simply creates a slightly more difficult means of tracking it down and a way in which Apple itself can be directly involved in the spreading of such an exploit. URI protocol handlers are great - we're using two special ones in PulpFiction (which are not accessible outside the application) - but Apple's got a security issue worthy of some thought here: URI handlers are easily registered without user knowledge or input.

Once an app is on your disk, do you really know what URI schemes it handles and why it offers to handle them? I am not advocating locking down the system. Every application needs to launch and most applications need to write, read, and delete files. Prompting the user whenever an application attempts to function for itself is not the way to go.

However, very few applications need their own public URI handlers (or to switch ownership of existing ones to themselves).

6 Responses to "Mac OS X URI Handlers"

  1. The answer, then, is to prompt the user when first assigning the handler, not prompt every time it's used like some advocate.

  2. Your example with the game doesn't need a URI handler. If you install and run it (2 steps which have happened in your example), it can do the same stuff that it could do with a URI handler!

  3. Ben, my example does need a URI handler. It's far more nefarious that way. Clearly Apple wouldn't host an app that, when launched, erased data. It'd have to be sneakier to get through.

  4. Erik, a time-delayed trojan horse attack would work just as well. Have all copies of SuperHappyFunGame spontaneously send your email box to the author on Dec 31, 2004. Not even Apple would know this was in there until them. Protocol handlers would not be needed for that, either.

    Once it's on the user's computer, it's the user's responsibility. If you don't trust it, don't run it. If you trust it, blame the author when it fails, not the OS.

  5. I have to agree with Ben and codepoet. You could download EvilGame 1.0 from .Mac, it could say it needs to be updated a few weeks later, and the update could wipe out your home folder or install an e-mail worm or anything else. No need for a URI handler. Apple wouldn't know until it's too late -- because the update is NOT on Apple's iDisk.

    In fact, you could download any OS X app off the Web and it could wipe your data on, say, Aug. 19, 2004. Who would know until then? Basically, anything you put on your computer you have to trust. The only scary thing about the URI handler issue is that you could browse to a Web site and have your system compromised right away. As soon as that's completely fixed, I don't see that there's any problem.

    Jared

  6. In other words, Jared, you agree with me: the ease with which apps can register for URIs is too great.