Late Friday, Apple released Security Update 2004-05-24, for [Panther] [su10.3] and [Jaguar] [su10.2]. Apple's description for the Panther version: > This update delivers a number of security enhancements and is > recommended for all Macintosh users. This update includes the > following components: > > HelpViewer [*sic*] The description for the Jaguar version: > Security Update 2004-05-24 delivers a number of security > enhancements and is recommended for all Macintosh users. > This update includes the following components: > > Help Viewer > > Terminal Indeed, these are the only updated components. (You can see for yourself by downloading the updates. The `.pkg` updaters are packages, which are just folders that the Finder treats as a single file. Inside the package is a "Contents" folder, inside which is a file named "Archive.bom". ("bom" stands for "bill of materials".) You can use the `lsbom` command-line tool to list all of the updated files specified in a `.bom` file.) The updated version of Help Viewer for Panther is version 2.0.6. The new version of Help Viewer fixes at least one specific security exploit: Help Viewer no longer executes scripts when it receives a 'help:runscript' URI which originates from any application other than Help Viewer itself. Thus, after installing this security update, it is now safe to assign the 'help:' URI protocol to Help Viewer. About 'help:runscript' URIs --------------------------- When I first wrote about this 'help:' URI security exploit, I mentioned that I wasn't aware of any help books which actually took advantage of this feature. That was sheer laziness on my part, and for that I apologize. In fact, as a simple BBEdit multi-file search for "help:runscript" shows, it's a commonly used feature in many of Apple's own help books. Most frequently, it's used to create a link that opens an application or a particular System Prefs panel. For example, each of the Mac Help pages relating to sound -- choosing an alert sound, setting the volume, setting input sources, etc. -- has a link at the bottom that says, "Open Sound preferences for me". If you click this link, the System Prefs application launches, and displays the Sound panel. Help books are just HTML files. The source code for such a link looks like this (note that I've added line breaks for readability; the actual href attribute should be one long line): Open Sound preferences for me Because Help Viewer is the default handler for the 'help:' URI protocol, when any other application attempts to resolve such a URI, it gets passed to Help Viewer. Prior to the version released in this security update, you could pass a 'help:runscript' URI from any source, and Help Viewer would execute the script specified in the href attribute. Hence the security problem -- the 'disk:' and 'disks:' URI protocols, ostensibly unrelated to 'help:' -- could be used by a malfeasant to silently mount a disk image on your computer. Then, a 'help:runscript' URI could be used to launch apps on the mounted disk image. This could happen simply by loading a web page; with a couple of frame and meta refresh tags, the disk image could mount and the script could execute without your having to click on anything. The stop-gap measure I recommended prior to the release of the security update was to disable the 'help:' URI protocol, using RCDefaultApp (or More Internet or MisFox; any of which would do the job). Doing so plugged the security hole, but also prevented *any* 'help:' URIs originating outside Help Viewer from working. For example, a 'help:search' URI will perform a search in Help Viewer; e.g. to search for "sound volume": Search Help Viewer for information about 'sound volume'. Disabling 'help:' disabled *all* help URIs; but the only dangerous ones were 'help:runscript' URIs. This is exactly what the new version of Help Viewer limits. You can try it for yourself. Here are the two links shown above: Open Sound preferences for me. Search Help Viewer for information about 'sound volume'. The first -- a 'help:runscript' URI -- no longer works when initiated from a web browser. Prior to the security update, it did. (When passed a 'help:runscript' URI from another app, the updated Help Viewer now logs a message to your console: "Help Viewer[4869] help://runscript called by another application!".) The second -- a 'help:search' URI -- still works from any application, if you have Help Viewer specified as your default handler for 'help:'. This is a good thing; Apple has prevented precisely what was dangerous, and nothing else. It's also worth noting that even when you disable the 'help:' protocol, or point it at a dummy application such as Chess, Help Viewer still handles all 'help:' URIs which originate from within Help Viewer itself. This makes sense, in the same way that web browsers like Safari, Camino, and IE always handle 'http:' URIs on their own, no matter if they're specified as your default web browser. Thus, if you're paranoid, you can leave the 'help:' protocol disabled, and 'help:runscript' URIs will still work for you from within Help Viewer. For what it's worth, I have restored Help Viewer as my default handler for 'help:'. About the Jaguar Update ----------------------- I don't have a Jaguar installation, so I have no means to investigate the Jaguar version of the security update. We can probably assume that the Jaguar Help Viewer has been updated similarly to Panther's, but I have no idea what's changed in Jaguar's Terminal. What About 'telnet:', 'disk:', and 'disks:'? (Or: Why I See No Reason You Should Install Unsanity's Paranoid Android) -------------------------------------------- Security Update 2004-05-24 contains nothing in response to the ['telnet:' URI vulnerability] [telnet] I wrote about Friday. My advice remains that you should use [RCDefaultApp][] to disable the 'telnet:' protocol. As for 'disk:' and 'disks:', you should leave these protocols disabled as well. The specific security problem that led to this discussion has been closed with the updated version of Help Viewer, but it's a terrible idea to allow disk images to mounted automatically in response to a URL from a remote source, and it can be exploited for harm. E.g., see the example exploit linked from [Unsanity's Paranoid Android Whitepaper] [paw]. But first, what is Paranoid Android? Unsanity describes it thusly: > A vulnerability in Apple's Mac OS X results in a potential > situation in which a malicious person could execute > arbitrary commands on your machine, such as deleting your > home directory, or doing other harmful actions. This > vulnerability involves the use of URL "schemes". These are > the part of a web address that specifies what program > should be used to handle the address. > > Paranoid Android can protect you from this potential > vulnerability until Apple makes an official fix available. > It does this by watching the URL schemes that are requested > and delaying them until you've had a chance to say whether > you'd like to proceed or not. If you know that the url > that's being loaded is legit, go ahead, but if it looks > suspicious, Paranoid Android gives you an opportunity to > cancel it. But that only describes what Paranoid Android *does*, not what it *is* or how it works. What it is is an Application Enhancer module, a.k.a. a "haxie". How it works, loosely, is that it injects code and/or data into every running application -- while haxies do not modify the applications on disk, they do their thing by violating the boundaries of protected memory. Thus, Paranoid Android is a haxie that injects code into every application, which code apparently intercepts calls to Launch Services which are attempting to resolve URIs. Thus, while Paranoid Android may well solve the problem of malicious use of URI protocols and their default handlers as registered in Launch Services, it may also introduce problems of its own. The Paranoid Android Whitepaper, written by the developer of Paranoid Android, Jason Harris, documents and links to two "benign sample exploits". The first is a legitimate threat. It works like this: 1. A Mac OS X users visits a web page. 2. Using frames and meta refresh tags, the web page sends a 'disk:' URI, which, with default settings, causes a disk image to be automatically mounted on the user's system. 3. This disk image contains an application bundle, the Info.plist file of which specifies that this app wants to register a custom URI scheme. For example, in Unsanity's sample exploit, the pertinent snippet of Info.plist is this: CFBundleURLTypes CFBundleURLName Malware URL CFBundleURLSchemes malware which registers the application as the default handler for the 'malware:' URI scheme. 4. Upon displaying this application in a Finder window, the Finder automatically registers the application for the URI scheme it has asked to handle. (As far as I can tell, the Finder only does this if the app has been displayed -- merely mounting the image doesn't register the URI scheme in my testing.) 5. After waiting a few seconds for the disk image to mount, the remote server sends a URI using the protocol the application just registered for. (E.g. in the case of Unsanity's example, a "malware:whatever" URI.) The user's web browser passes the URI to Launch Services for resolution, and Launch Services launches the application. Here, the user's goose is potentially cooked -- once the application is launched, it has free reign. The only action the user took was to load a web page; the rest happened automatically. Thus, Unsanity's whitepaper describes a legitimate threat. However, I do not agree with their advice as to how to deal with this threat: > Until Paranoid Android, there was no way of protecting > against this attack, which freaked me out enough to write > Paranoid Android.  :) And again: > Because this sample exploit registers its own URL scheme, > none of the methods people had been using involving > disabling certain scripts, moving Help.app or changing the > 'help' URL scheme would protect against it. At this time, > only Paranoid Android provides protection from it. While indeed this has nothing to do with the 'help:' scheme, it is simply *not true* that "only Paranoid Android provides protection from it." If you have disabled the 'disk:' and 'disks:' protocols -- and turned off the "Open 'safe' files" preference in your web browser -- this exploit will fail, because the disk image will not be mounted. Unsanity's second sample exploit, added today, uses an 'ftp:' URI pointing to a directory on unsanity.com. With default settings on Panther, 'ftp:' URIs are handled by the Finder, which will in turn mount the specified directory in the 'ftp:' URI as though it were a network server. Once this happens, and the Finder displays the "OSXMalware" application in that folder, it will once again register the custom URI scheme specified in the app's Info.plist file. (In this case, 'guardian452:', which is a different protocol than the 'malware:' scheme used in the first example.) However, in my testing, the OSXMalware application never gets launched in response to Unsanity's sample exploit. Yes, the custom protocol is registered in Launch Services, but so long as the application is only available on the remote FTP server, it won't be launched. In fact, even if you double-click the app icon, the Finder will warn you before launching the app: "The application 'OSXMalware' is on an FTP server. Are you sure you want to open 'OSXMalware'?" Thus I conclude Unsanity's second sample exploit is in fact not a legitimate exploit at all. Even if I'm wrong, however -- i.e. perhaps I'm unable to reproduce the exploit here, but it works elsewhere -- Paranoid Android would not be the "only" solution. Choosing something other than the Finder as the default handler for 'ftp:' URIs would close this hole in the same way that disabling the 'disk:' and 'disks:' protocols closed the first one. Therefore I cannot recommend the use of Paranoid Android. As far as I have determined (and admittedly, that's an important disclaimer), every security problem "solved" by Paranoid Android can also be solved by changing or disabling Mac OS X's default URI handlers using RCDefaultApp. RCDefaultApp uses supported API calls to modify your Launch Services settings, and should therefore conflict with nothing. Paranoid Android uses completely unsupported mechanisms to inject code into every running application, and therefore has the potential to conflict with anything. If there is a demonstrable exploit that cannot be disabled by supported means, I'd like to see it. [su10.3]: http://www.apple.com/support/downloads/securityupdate__2004-05-24_(10_3_3).html [su10.2]: http://www.apple.com/support/downloads/securityupdate_2004-05-24_(10_2_8).html [telnet]: /2004/05/telnet_protocol "Using the 'telnet:' URI Protocol to Delete Files" [RCDefaultApp]: http://www.rubicode.com/Software/RCDefaultApp/ [paw]: http://www.unsanity.com/haxies/pa/whitepaper "Unsanity: 'Paranoid Android Whitepaper'" [pa]: http://www.unsanity.com/haxies/pa/ "Paranoid Android"