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"