PGP key for vulnerability reports

[Richard Johnson]

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.html Browsers
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.

>
> > On Sat, Nov 23, 2013 at 5:01 PM, Richard Johnson <
> rjohnson at sourcefire.com> wrote:
> >>
> >> We observed that you currently filter .exe and .bat files so we assume
> it is your intention to filter arbitrary download & execute scenarios. In
> this case a .jar file is an executable format that runs with full user
> privileges if the JRE is installed. This behavior is different that what a
> user would normally expect when clicking on a .jar file in a browser. Java
> will run in a more secure sandboxed context when executed from within the
> browser, ShellExecute is equivalent to executing the path from the Run
> Command dialog. Other executable programming language files such as python
> would also be executed if the interpreter was installed and this is not
> expected behavior in a browser.
>
> We actually don't do any filtering by extension - there's no filtering
> other than the scheme handling mention in the previous email.
> Any filtering you've observed is done by the "http" class handler (which
> is what we're counting on).
>
>
The the .exe filtering that was reported is actually Windows functionality
that warns when running a remote executable. That warning comes from within
the ShellExecute API but does not apply in the case of jar or py files. I
thought there were checks in the code but that doesn't seem to be the case.


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


I specified IE because you can guarantee it will be present on Windows
machines. You could wrap the control within the pidgin client and the user
would not actually see a browser. I think filtering file:// is a better
route though, I'm not familiar enough with the WebBrowser control to know
if they would filter the same as the actual IE browser.


Cheers,
Rich



> -D
>
>


-- 
Richard Johnson
Sourcefire VRT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20131123/1d9f0f0a/attachment-0001.html>