PGP key for vulnerability reports

[Daniel Atallah]

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.

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

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

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