PGP key for vulnerability reports

[Richard Johnson]

I wasn't intending to confuse the current patch situation though, that's a
suggestion to consider for the future because there's no room for error.
The current solution of passing the file:// url to explorer.exe /select
should be sufficient for now.


On Tue, Jan 14, 2014 at 10:40 AM, Richard Johnson
<rjohnson at sourcefire.com>wrote:

> The reason I suggest using the browser to handle file:// URLs is that this
> is an old problem that has been worked around many times. The default
> behavior is more secure if you pass a file:// url to the browser than if
> you pass to ShellExecute and the user will have already configured the
> behavior they are comfortable with if they didn't like the default.
>
>
>
> On Mon, Jan 13, 2014 at 9:44 PM, Mark Doliner <mark at kingant.net> wrote:
>
>> On Mon, Jan 13, 2014 at 2:35 PM, Rich Johnson (richjoh)
>> <richjoh at cisco.com> wrote:
>> > VRT-2013-1001 - Yves Younan and Ryan Pentney of Sourcefire VRT
>> > VRT-2013-1002 - Yves Younan and Pawel Janic of Sourcefire VRT
>> > VRT-2013-1003 - Yves Younan of Sourcefire VRT
>> > VRT-2013-1004 - Yves Younan of Sourcefire VRT
>>
>> Noted. Thank you.
>>
>> > For the file handling vulnerability, it might make the most sense to
>> whitelist http/https and warn on
>> > all other strings, then do a CreateProcess on iexplore.exe (or pull
>> default browser string from
>> > registry) and pass the URL as an argument. Our analysis showed that a
>> ShellExecute has different
>> > behavior than that of the browser itself.
>>
>> To clarify... you're saying we could pass the file:// URI directly to
>> the browser instead of going through ShellExecute? My currently line
>> of thinking is that the browser isn't the most appropriate handler for
>> file:// URIs. I think we're better off showing the file in a file
>> manager. Or, if the system has a handler registered for file:// URIs
>> then we should show a warning before calling it.
>>
>> > There was also a followup email by Yves that showed the URL handling
>> bug to be exploitable in KDE in case you hadn't seen that yet?
>>
>> Yes! I did see that comment. In my testing (and in Yves' email), the
>> KDE file manager shows a prompt "Do you really want to execute
>> 'file:///whatever'? That seems sufficient to me for now. I think a
>> better solution would be for Pidgin to show a more tailored warning...
>> but I personally feel that can wait until 3.0.0.
>>
>> > We will be posting these advisories on our blog and releasing the
>> signatures to the open
>> > source snort community in tandem with your release, so please let us
>> know when you
>> > get the CVE numbers so we can add them to our local copies.
>>
>> Will do.
>>
>
>
>
> --
> Richard Johnson
> Sourcefire VRT
>



-- 
Richard Johnson
Sourcefire VRT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20140114/e9e4d879/attachment.html>