There is a lot of talk about how an application should handle URL protocol handlers. Jesper Johanson has expressed his thoughts, as has David LeBlanc, Billy Rios, Window Snyder and pdp. Billy Rios just detailed yet another potential attack vector for protocol abuse.

I don’t think it is the responsibility of the calling application to perform input validation for the called application. However, I do think it is the responsibility of the calling application to ensure that the arguments to the called application are passed along properly, which is a subtle but important distinction.

When an application registers a URL handler there are only so many ways that it can do this. For the FirefoxURL handler Firefox specified HKLM\FirefoxURL\shell\open\command as

“path\to\firefox.exe” “%1″

Skype registers itself under the callto: protocol as

“C:\Programmer\Skype\Phone\Skype.exe” “/callto:%1″

Windows Address Book registers itself under the ldap: protocol as

“C:\Programmer\Outlook Express\wab.exe” /ldap:%1

And those are pretty much the different variations we can find for registering URL protocol handlers that are to be called from the command line. Most register with quotes directly around the %1 placeholder, some have quotes around the argument and the placeholder and others don’t even surround the placeholder with quotes.

In all these cases you can avoid the potential for mishap by either escaping quotes or whitespace. It should be possible for Internet Explorer, Firefox, Opera and Safari to embed a tiny bit of string handling logic into these very defined cases.

Coincidentally, Jesper published his post about how Mozilla does not escape these quotes either in his blog post on July 20. I had just written up this very same flaw in a vulnerability report two days before, on July 18, together with a proof-of-concept exploit that jumps from Firefox to Thunderbird. Separately from all of this the Mozilla Corporation were farsighted enough to include their “-osint” fix from Firefox 2.0.0.5 in Thunderbird 2.0.0.5, which was released on July 19.

As such, I am that vulnerability report unedited in my next article :)