PGP key for vulnerability reports

[Richard Johnson]

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


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 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.
>
> 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.
>
>
>
> On Sat, Nov 23, 2013 at 11:21 AM, Daniel Atallah <datallah at pidgin.im>wrote:
>
>> On Mon, Nov 18, 2013 at 5:27 PM, Richard Johnson <rjohnson at sourcefire.com
>> > wrote:
>>
>>> Windows can be forced to map the first page via a VirtualAlloc if the
>>> memory is sufficiently filled / fragemented. This no longer applies in
>>> Windows 8 I believe but for all others it does. I used to work on the
>>> Microsoft Security team and can confirm this to be true. I'm not positive
>>> about whether there are specific mitigations against this in OSX or vanilla
>>> Linux kernel. Either way, most vendors consider a writeAV to be
>>> exploitable.
>>>
>>> Yeah, the URL handling bug is particularly annoying because we cannot
>>> write a signature for it from an IPS perspective.
>>>
>>
>> I've looked into the URL handling issue and this is what's going on:
>> We actually don't do any filtering on the URLs based on anything other
>> than URL scheme (mainly because we can't be in the business of deciding
>> what links are safe or not past a trivial level of some scheme
>> whitelisting).
>> The way it works is pretty simple: only "http", "https", "ftp", "mailto"
>> schemes are passed to ShellExecute as classes to be handled - anything else
>> is sent to ShellExecute to be handled by the "http" class.
>> The way that I understand it, the browser is then responsible for
>> handling whatever gets past that point (the same effect as if the user
>> clicked the link directly in the browser).
>>
>> If there is a better strategy that's reasonable to implement or there's
>> an incorrect assumption in the above, we'd be interested to know about it.
>>
>> -D
>>
>
>
>
> --
> Richard Johnson
> Sourcefire VRT
>



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