Insomnia Security Advisories: Pidgin IM Insecure URL Handling Vulnerability

[James Burton]

Hi Guys,

Thanks for the prompt replies.

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.

If you download URLProtocolView from
http://www.nirsoft.net/utils/url_protocol_view.html and run it on your
systems you will see that there are many more than just file:// or
http:// etc. My system has 76 installed.. How many of those do you
really need to give people access to from within a Pidgin IM session?
Implement a whitelist of valid protocol handlers would be a far better
solution than to blindly trust whatever the users browser does - which
is what you are doing at the moment.

Regards

James Burton

Insomnia Security
http://www.insomniasec.com

On 22/07/2011 11:02 a.m., Eion Robb wrote:
> On 22 July 2011 06:01, Daniel Atallah <daniel.atallah at gmail.com
> <mailto:daniel.atallah at gmail.com>> wrote:
> > The functionality that handles "file://" URIs is intended to handle
> > links that are generated by Pidgin itself (links to files after file
> > transfer is complete).
> Sending file:// links in messages is also very useful too, especially
> for network shared files on a corporate system.
>
> > I guess a solution could be to be to make it so that only handles
> > file:// URIs that we generate - I'm not sure how hard that's going to
> > be to implement.
> > Another option would be to prompt the user to confirm that they want
> > to open the URI.
> Maybe it should only confirm if it's for a file:// uri that wasn't
> generated by libpurple?
>
> Perhaps another option is to do a 'show file in explorer' for all
> file:// uri's so that file:// uris are never executed?
>
> > I wasn't able to find any good documentation that outlined how others
> > have dealt with this type of thing - are you aware of any such
> > documentation?
> I couldn't either.  Best I could find was that browsers will prompt to
> confirm for Run and Save like they would for any other type of download.
>
> --
> Cheers,
> Eion