PGP key for vulnerability reports

[Rich Johnson (richjoh)]

Hi Mark, 

The timeline sounds good and we appreciate you handling the CVE numbers. We have reviewed the patches and they look good. 

Credit should be as follows: 

VRT-2013-1001 - Yves Younan and Ryan Pentney of Sourcefire VRT
VRT-2013-1002 - Yves Younan and Pawel Janic of Sourcefire VRT
VRT-2013-1003 - Yves Younan of Sourcefire VRT
VRT-2013-1004 - Yves Younan of Sourcefire VRT

For the file handling vulnerability, it might make the most sense to whitelist http/https and warn on all other strings, then do a CreateProcess on iexplore.exe (or pull default browser string from registry) and pass the URL as an argument. Our analysis showed that a ShellExecute has different behavior than that of the browser itself. There was also a followup email by Yves that showed the URL handling bug to be exploitable in KDE in case you hadn't seen that yet? 

We will be posting these advisories on our blog and releasing the signatures to the open source snort community in tandem with your release, so please let us know when you get the CVE numbers so we can add them to our local copies. 


Best Regards, 

Rich Johnson
VULNDEV Team Lead
Sourcefire VRT


-----Original Message-----
From: Mark Doliner [mailto:mark at kingant.net] 
Sent: Sunday, January 12, 2014 3:21 AM
To: Pidgin Security; Richard Johnson; Yves Younan
Subject: Re: PGP key for vulnerability reports

Questions for Robert and Yves: Are you ok with us requesting CVE numbers for these from our contact at Red Hat? Can we give credit to you for finding these problems (in our ChangeLog, vulnerability posting at https://pidgin.im/news/security/, and in our request for CVE numbers)? If so, who should we credit? "Discovered by Sourcefire VRT"? "Discovered by Yves Younan, Sourcefire VRT"?

Our fixes for all four issues are attached, encrypted for rjohnson at sourcefire.com. I would like to request CVE numbers from our contact at Red Hat on Mon, Tue or Wed. I would like to set an embargo date of Jan 23, morning US pacific time. Does this sound ok to everyone? I'm flexible.

VRT-2013-1001, VRT-2013-1002, and VRT-2013-1004: Tomasz and I both confirmed that these bugs exist in Pidgin 2.10.7. Tomasz has committed fixes for all of them to our private 2.x.y branch (revisions ec15aa187aa0, 4c897372b5a4, and 6bd2dd10e5da, respectively).
Additionally, for VRT-2013-1001 (the Gadu-Gadu bug) Tomasz will commit the fix to upstream libgadu after we've released our 2.10.8 publicly.

VRT-2013-1003 (exec'ing file:// links in Windows and elsewhere) is the least straight-forward of the bunch. This bug was actually reported to us in 2011 and we attempted to improve it then. We even got a CVE number and added the buggy code "if uri_starts_with_file://file:// then show it in Explorer." See https://pidgin.im/news/security/?id=55
for details.

I think this is mostly only a problem on Windows. For most other configurations we either open a file manager or prompt the user.

The current behavior is:
- If Windows and link is "file://file://blah" then open Explorer at the file's location.
- Otherwise, if Windows then attempt to exec the file.
- Otherwise, if 'gnome-open' exists and GNOME_DESKTOP_SESSION_ID env variable is set then open file browser at the file's location (on Ubuntu 13.04, at least) using "gnome open /usr/bin/blah".
- Otherwise, if 'kfmclient' exists and KDE_FULL_SESSION and KDEDIR env vars are set then prompt the user "are you sure you want to exec /usr/bin/blah?" (on Ubuntu 13.04, at least) via Konqeror using "kfmclient openURL /usr/bin/blah"
- Otherwise, if on OSX then "open /usr/bin/blah." I think this sometimes execs the file.
- Otherwise, use user's configured web browser. Firefox prompts.
Chrome downloads the file (or would presumably display it if it's HTML or image).

The ideal behavior that I would like to see is:
1. User clicks file:// link
2. Something shows the user a dialog "WARNING: Opening this is dangerous. Are you sure you want to continue?" This dialog could be Pidgin, or could be handled by the OS, desktop environment, file manager, browser, etc.

I also think it's acceptable for us to pop open a file browser at the file's location, but not as user-friendly and not any safer for the user.

Disabling file:// links completely is reasonable, but I think it's more extreme than need be.

I fixed the brokenness of our Windows link opening code in revision b2571530fa8b. I'd prefer for us to wait until 3.0.0 to add an "are you sure?" confirmation prompt.