Insomnia Security Advisories: Pidgin IM Insecure URL Handling Vulnerability

[Evan Schoenberg, M.D.]

On Jul 22, 2011, at 8:55 PM, Daniel Atallah wrote:

> 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?

I agree, Daniel. As long as clicking the link requires user intervention, and the link can't inadvertently be an executable file (as could happen with a file:// link handled natively), I think it should be allowed.

Imagine that I have an in-house application that registers for a particular URI, and I use Pidgin to talk to other people who have that same application.  This is one example of a use case in which we could not know in advance about a benign URI... and it would be overly restrictive to block it.

-Evan