Insomnia Security Advisories: Pidgin IM Insecure URL Handling Vulnerability

[Daniel Atallah]

On Fri, Jul 22, 2011 at 01:30, Paul Aurich <paul at darkrain42.org> wrote:
> On 2011-07-21 16:33, James Burton wrote:
>> Thanks for the prompt replies.
>
> Thank you for reporting this.
>
>> Eion's suggestion of giving the option to show file in explorer would
>> definitely prevent file:// being abused to cause code execution, but it
>> wouldn't fix the root cause of the issue. The fact is every Windows
>> system has a many URL protocol handlers installed - any of which has the
>> potential for abuse. I merely chose file:// because it was the most
>> obvious to demonstrate.
>
> Yep, though I believe there have been a number of shell vulnerabilities
> such that even viewing the file lead to exploitation -- I still think
> this is the appropriate solution.
>
> Pidgin currently has two types of URI handlers:
>   1) URIs handled explicitly by Pidgin.
>      These currently include http, https, ftp, gopher (side note:
> Really!?), mailto, and file.  The first five invoke the user's browser
> (http "open" handler) via ShellExec.  file, as we know, can be abused,
> so I think changing this to show the file in Explorer is the appropriate
> resolution here.


IIRC gopher is used as an ugly hack for mxit somehow.

>
>   2) All URI schemes under HKCR.  These are explicitly passed to the
> URI handler (same code as first five in #1), in essence, passing the
> buck off to the user's web browser.
>
> There have been security issues in the interaction between the browser
> (Firefox being the one I recall) and Windows when it comes to URL
> handling, so perhaps we should still reconsider registering all classes
> handled by Windows, so that Pidgin is not a vector for exploitation of
> browser security issues.
>
> Thoughts?

I don't necessarily have a problem restricting the list of schemes
somewhat, but I guess I don't know if I agree that there is a real
problem in just passing stuff through the browser like we are doing.

Assuming that the user is actually using their default web browser
(which I think is a reasonable starting assumption), then anything
that Pidgin throws at the user is handled in the same way that any
other random URIs that they encounter online.  If the user's browser
isn't trustworthy, it seems like worrying about something like this in
Pidgin is like closing the fan vents while your window is open.  It
doesn't seem reasonable for us to try to evaluate and decide what is
safe or not for each scheme - we're going to get it wrong or be overly
restrictive - this is a problem that the browser folks have clearly
had to spend a lot of time thinking about, so why wouldn't we leverage
that work?

To be clear, I'm not suggesting that the current file:// handling
isn't a problem.

Am I completely off base here?

-D