PGP key for vulnerability reports

[Richard Johnson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20131123/3626dbce/attachment.html>