SecureMac, Inc.

Computer security news. Just for Macs.

Get the latest computer security news for Macs and be the first to be informed about critical updates. Industry news, security events and all you need right at your fingertips. Malware threats change daily, so keep up to date on the latest developments to help ensure your privacy and protection. You can never be too safe.

Mac OS X URI Handler Security Issues & Exploits

Posted on May 8, 2004

Recently, Mac OS X has been known to be vulnerable to many new remote exploits.

Theses exploits are allowing to remotely execute code on your computer when you surf a webpage. Most of the people reading about theses vulnerabilities often missunderstand or apprehend the impact it can have, for a user.

While many people will use Paranoid Android, from Unsanity, and it does protects you well, many don’t even know about the vulnerability in the first place. Theses can lead to the total erasement of your personal data (by erasing /Users/you), to install a trojan on your computer. Root rights aren’t needed, and once the trojan in, the attacker will have a pleasure to steal your admin password the first time you’ll type it.

Your first allie is common sense: you will see if something is happening, and if you cannot stop it, you can always unplug your machine, backup your data and re-install Mac OS X.

We will look at a new vulnerability, which I just issued, involving OpenSSH and the URI handlers.

Adv: safari_0x06

Release Date: Private

Affected Products: Mac OS X >= 10.3.3, Various
Browsers, possibly others platforms/browsers

Fixed in: Not fixed.

Impact: Remote code execution.

Severity: High.
Vendors: Notified (23/02/04)

First of all, what are URI handlers ?

When you click a link, starting with http://, ftp:// or some other, Mac OS X’s LaunchServices will lookup its URI database for the program which is supposed to handle this link. This database is stored in InternetConfig2, which is browseable easily using the More Internet preferences panel.

So that’s it, the HelpViewer vulnerability used the help:// URI to launch HelpViewer and exploit it, while the Self-Registring URI vulnerability mounted a disk image including an application claiming to handle the URI of a random thing, like iamanexploit://. A few seconds later, a link starting by iamanexploit:// would be called, and Mac OS X’s LaunchServices would call that new application (which could execute whatever it wanted).

Now, what about OpenSSH ?

Like many other protocols, SSH can be called through it’s URI handler, which is ssh://

Many people looked up all the applications being called the URI’s and claimed that OpenSSH wasn’t vulnerable. But as usual, if you look deep, and think a bit different, as Apple would argue, there’s often things they left out. For OpenSSH, that’s the ProxyCommand functionality. This option allows ssh to call an application which will act as a proxy between the ssh client and the ssh server. It is sometimes used to be able to use OpenSSH over HTTP Proxies when no other outside connection is allowed. The problem lies in the fact that when using this option, the ssh client will blindly launch any proxy application you’ll tell him, even if that application… is an trojan, an exploit, or anything, without checking.

Details and Exploitation

For this option to work, you would usually call ssh:// -o’ProxyCommand your_program_or_trojan_or_bash_commands’

While this might work on Linux (Konqueror is not affected), this does not on OSX. We’ve to use yet another trick:

We will ask ssh to read a configuration file which will be in a known path: a disk image which we will mount, or an ftp server.

The syntax for the command is simply ssh:// -F /Volumes/DiskImage/configuration_file

Here we face the last problem, Apple, in it’s recent Security Update (CAN-2004-0486) parsed what was being sent to the URI handlers with the LaunchServices, and removed file pathes (like /Volumes/etc or :Volumes:etc..).

Using a well known obfuscation method, I used URL Encoding to write the file path, which LaunchServices didn’t checked, but which still means the same path, so here the final command:


As you can see it being blocked when Paranoid Android is installed :


Now, still using those precious URI’s, we just make sure to have mounted the disk image previously, using disk://, or simply, which will behave about the same as the disk image.

Final exploit


Demo is available here.

If you’re interested in OpenSSH, I suggest you reading my article about it’s advanced option here.

Join our mailing list for the latest security news and deals