Mac OS X LaunchServices Vulnerability And The Need For Paranoid Android

A whitepaper by Jason Harris

Paranoid Android is now an open source project for those interested.

Update - May 23, 2004

When I originally wrote this whitepaper, I was using an app called MisFox to change protocol helpers. MisFox didn't allow me to change the URI helper for the 'disk' or 'disks' protocols, so I was under the impression that they couldn't be changed. Hence, I believed that Paranoid Android was the only way to prevent being exploited by the vulnerability described below.

My current understanding is that there are five infection vectors that can be used with Safari (more and fewer with various other web browsers). If "Open Safe Files After Downloading" is enabled, a 'zip' file can be used. If not, 'disk', 'disks', 'ftp' and 'afp' can be used. There's anecdotal evidence that these don't work in Jaguar or in some other web browsers, but they do work in Safari on Panther.

This means that for those who do not wish to use Paranoid Android, there are other methods of protection - use RCDefaults to disable the 'disk', 'disks', 'ftp', and 'afp' protocols, and turn off "Open Safe Files After Downloading". Paranoid Android is not the only solution.

However, I still recommend using Paranoid Android instead of remapping protocol helpers. It's possible that there are other infection vectors I'm not aware of, and also, once Apple resolves this issue, it'll be easier to turn Paranoid Android off than it will be to remap the protocol handlers. Paranoid Android can be installed for all users, and is significantly easier to use than remapping protocols for every user on the system.

On a different note, the FTP sample exploit below had a problem (the executable bit wasn't set on the executable). This is now resolved, and the sample exploit should work properly.

My apologies for any confusion that either of these issues may have caused. I'm going to leave the original text intact below for posterity.

Executive Summary

This is a nasty security vulnerability and you'd better install Paranoid Android until Apple fixes it.

Background Information

Apple’s OS X has seen its first major security vulnerability. Apple hasn’t yet released a fix (although they are purportedly working on one), and there’s been lots of rumor, speculation, and flat-out incorrect fixes coming from the user community in the meantime. This paper is an attempt to explain the issue, explain why other fixes are incomplete, and present the rationale for Paranoid Android, my solution to the issue.

My current understanding of this vulnerability is that there are two “infection vectors” and two “exploitation vectors”.

Infection Vectors

  • The malware executable is automatically mounted on the target’s computer via an URL over which the target has no control. An example is a very small html frame in an otherwise innocous webpage that redirects to an URL with a scheme of 'disk', 'ftp', or 'afp'. No intervention from the user is required, all they have to do is surf to the malicious webpage and the malware executable will be mounted. Apple should prevent against this, but I’m not sure how. Restricting schemes that can be used in meta refresh tags would be one way, but there’d be lots of ways around it, and doing so would also restrict lots of legitimate uses.
  • The malware executable is not automatically mounted without user intervention, instead, the target user must be fooled into clicking a link that mounts the executable. An example is a link titled “Click this to receive your free radio!”, which, instead of giving the user a free radio, mounts malware onto his computer. I don’t believe that Apple should try to protect against this type of infection because this is a social and educational issue, not a technical one. “You can’t protect users against their own stupidity.”

Now that the malware executable is present on the target’s machine, lets look at ways that the attacker can launch the malware executable and deliver its payload. The payload can be anything that the target user has permissions to do, which includes wiping the target user’s home directory, asking the target user to authorize the malware to gain super-user privs, and including emailing innocous infection vectors to everyone in the target user’s address book.

Exploitation Vectors

  • The attacker can use an existing, legitimate service provided by the operating system to execute the malware. Examples are using the 'runscript' scheme and the 'help' scheme. These schemes have high legitimate utility and should not be disabled, but they should also not be co-optable. Apple needs to fix this, no clue how.
  • The attacker can register its own URL scheme handler, which will be automatically registered with LaunchServices when the malware is mounted in the Infection Phase above. The attacker then simply directs the web browser to any URL using that scheme, and the malware will be executed by Launch Services. The ability to register URL schemes with Launch Services is invaluable (two of my own products use it!), but it doesn’t need to be done until the handler executable has been launched. If Apple changed this behavior, that alone would close this vector.

The point of all of the above is that this is a rather large problem without an easy solution. There’s lots of overlap between useful applications of this functionality and malicious ones, meaning that Apple can’t easily fix this without removing useful features from its operating system and from existing apps.

Sample Exploit

I’ve written a sample exploit that delivers and executes its payload without user intervention and operates by registering its own URL scheme handler. Until Paranoid Android, there was no way of protecting against this attack, which freaked me out enough to write Paranoid Android.  :)

If you click the sample exploit link below, here’s what will happen:

  • A disk image named “MalwareDiskImage” will be mounted on your desktop.
  • Alternatively, the FTP path will be mounted in the Finder if the Finder is set up as the FTP handler. This is the default behaviour and the only way to change it is via a third party application. If the Finder is not the FTP handler, it will just launch the application that is the FTP handler.
  • LaunchServices will read the “Info.plist” file of the application in this disk image automatically, and register the application as the default handler for URLs with a 'malware' scheme.
  • The webpage will wait 10 seconds, and then redirect to “malware:unused”, causing LaunchServices to launch the payload application within the disk image.
  • The application within the disk image will write a text file to the user’s home directory called “owned.txt” explaining that the machine has been exploited, will present an alert to the user, and will eject the disk image.

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.

benign sample exploit -->  innocousPage.html  <-- benign sample exploit

benign sample exploit 2 (FTP)-->  innocousPage.html  <-- benign sample exploit 2 (FTP)

Portions of this sample exploit are based heavily on a prior sample exploit at insecure.ws

Conclusions

Until Apple fixes this vulnerability, you should install Paranoid Android and surf safely.