PGP key for vulnerability reports

[Richard Johnson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20140114/81deebab/attachment.html>