PGP key for vulnerability reports

[Daniel Atallah]

On Sat, Nov 23, 2013 at 8:39 PM, Richard Johnson <rjohnson at sourcefire.com>
wrote:
>
> Yves was the original caseworker on this particular bug, so he can fill
in anything I've missed below. Comments inline.
>
> On Sat, Nov 23, 2013 at 5:32 PM, Daniel Atallah <datallah at pidgin.im>
wrote:
>>
>> On Sat, Nov 23, 2013 at 6:06 PM, Richard Johnson <rjohnson at sourcefire.com>
wrote:
>> >
>> > I also meant to mention that IE, Chrome, and Firefox completely ignore
the file:// URL handler now, whether you type it into the URL bar or click
on a link pointing to a file:// target
>>
>> I don't see this behavior in IE10, Chrome 31 or Firefox 25.0.1 on
Windows 7 - entering a file:// URL in the URL bar isn't ignored.  I didn't
try embedding it in a html page.
>> not
>
> Sorry, I'm not sure what I was observing with the URL bar (maybe its Win8
related), but more importantly using file:// is disabled from a remote
hosted webpage, which would facilitate a download & execute over WebDAV or
SMB.
>
> So what we observe is that in the case of pidgin a path of
file:///C:/windows/notepad.exe will actually execute notepad, whereas the
browser would prompt or download. It will also allow remote UNC paths which
will download and execute anything you specify without prompting. You can
see an example of this here:
http://5.9.64.146/pidgin-urlhandling.htmlBrowsers will ignore the
remote file:// link embedded in that page and
pidgin will download and execute the jar file if you have the JRE installed.

It looks like this may be browser specific behavior (or perhaps OS
specific).
I'm unable to to recreate this scenario on a Windows 7 test VM with the
http handler set to Firefox 25.0.1 (I do have Java 1.7.0_45 registered as
the handler for .jar files).
The ShellExecute call is what fails (returns ERROR_FILE_NOT_FOUND) - the
same thing that happens when I try to invoke
"file:///C:/windows/notepad.exe".

The behavior is clearly different than when using Start->Run with the same
URL.

>> >> We would advise against passing arbitrary file:// URLs to
ShellExecute. You could also make the link target explicitly visible if it
is not a HTTP URL.
>>
>> I'm not necessarily opposed to filtering out the "file" scheme, I
suspect that will result in some whining though.
>> Making the link more visible is probably a good idea - that's something
that's been mentioned a few other times. It is actually already visible in
a tooltip, but that's perhaps not as obvious is would be idea.
>>
>> >> You would need to use the MSHTML WebBrowser control or pass the URL
as an argument to iexplore.exe if you want to replicate the browser's
treatment of a URL.
>>
>> Both of these assume that IE is the target browser, which isn't an
assumption that we should be making.
>> Are you saying that the browser receiving the link via ShellExecute is
different than it being handled via the URL bar or a link in a page?  That
is not my understanding.
>>
>
> The browsers actively enforce origin policies as well as providing
sandboxed privileges vs passing directly to ShellExecute. An example from
Firefox is here:
http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/win/nsMIMEInfoWin.cpp

That looks like what I'm hoping the browser would do (and the filtering
that we've been counting on by sending everything to the browser).

I guess we probably should filter out "file" URLs using the file scheme,
but if we can't trust the browser just blacklisting that scheme doesn't
seem like it solves very much.
I don't like the idea of maintaining a blacklist of patterns that we should
be filtering (or a whitelist either for that matter) - it isn't a
reasonable thing for each application to maintain.

I won't have time to test this any time soon, but is it likely that we're
only vulnerable if the browser isn't doing the right thing (based on my
inability to recreate it above)?

What are the specifics of the OS and default browser configuration under
which you were able to demonstrate the issue?

Thanks,
-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20131127/ac77198f/attachment.html>