Saturday, September 1st, 2007

Firefox File Handling Woes

It seems recent URI remote command execution bugs in Firefox have long been forgotten.  Mozilla put out a patch in a lighting fast manner, probably spurring on bravado like the “10 Fucking Days!” claim overheard at Black hat USA.  Let’s take a closer look at the vulnerability, starting with an interesting piece of the description provided in MFSA2007-27


“…Further investigation by Secunia showed that a % not followed by a valid two-digit hexadecimal number also triggered the problem for the affected protocols. The Firefox and Thunderbird releases contain fixes that prevent the original demonstrations of this variant, but it is still possible to launch a file type handler based on extension rather than the registered protocol handler. A way to exploit a common handler with a single unexpected URI as an argument may yet be found. Since this handling is a property of the Windows Shell API this variant appears to affect other internet-enabled applications that pass these URIs to the Windows Shell.”

Well, to make a long story short, Nate and I have discovered a way to “…exploit a common handler with a single unexpected URI…”  Once again, these URI payloads can be passed by the mailto, nntp, news, and snews URIs, allowing us to pass the payload without any user interaction.  So, it seems that although the conditions which allowed for remote command execution in Firefox have been addressed with a security patch, the underlying file type handling issues which are truly the heart of the issue have NOT been addressed.    


    We contacted Mozilla a while ago about the issue and they are working on it.  We’re going to refrain from giving out the exact details of how this particular issue is executed (based mainly on the efforts and conversations we’ve had with Jesse Ruderman), but we’ll include a screenshot of a payload in action.  In the screenshot below, we use the mailto URI, which passes the URI to the Windows File Handler, which calls the appropriate program (in this case Windows Scripting Host), which in turn calls our attacker controlled file.  We’ve purposely pointed the Windows Scripting Host to a file that doesn’t exist as the error message allows the user to see that WSH is using the URI passed from Firefox.   


Posted by xssniper | Filed in Security

  • Pingback: » More Firefox URI handling security hiccups | Ryan Naraine’s Zero Day |

  • Resuna

    This appears to be another side effect of a general problem that both Apple and Microsoft have created.

    The real problem is that the OS doesn’t provide a way for applications to publish whether they are designed for sandboxed use or not. They have only one set of file type bindings (or only one mechanism to invoke handlers) for local use (say by Windows Explorer or Finder) and for use by documents in a sandbox (that would be used by browsers, mail software, and so on). So applications have to guess at what is safe or not, *or* maintain their own list of safe applications.

    All browsers using the native application bindings on Windows and OS X have been subject to this attack in the past. And they will remain subject to this attack in the future. The ONLY solution is to set up separate lists of applications to handle documents, and for these applications to use the “sandboxed list”. If the OS vendor doesn’t provide a mechanism to distinguish between sandboxed and unsandboxed applications and APIs, then the only guaranteed method of preventing this class of attack is to set up a separate set of bindings and lobby helper application developers to register with it.

  • MattLee

    is there a way threw about:config to prevent such security flaws? i know using about:config you can reduce firefox memory, how about security issues?

  • Pingback: CHIP Online 0-security-blog » Blog Archiv » Firefox plagt immer noch die URI-Lücke

  • Damont

    I’m using the following settings to prevent FF from calling external applications without user interaction:

    user_pref(“network.protocol-handler.external-default”, false);
    user_pref(“network.protocol-handler.external.mailto”, false);
    user_pref(“”, false);
    user_pref(“network.protocol-handler.external.nntp”, false);
    user_pref(“network.protocol-handler.external.snews”, false);

    When I click on, e.g., a mailto link, nothing happens, but I can still copy the e-mail adress to my mail client manually . . .

  • Pingback: EL-Equipo » Blog Archive » Firefox File Handling Woes

  • Benny K (Security4all)

    Put ‘network.protocol-handler.external’ in the filter and put the unused URI to false.

  • Simon

    NB: A better work-around would be to toggle the following prefs instead:

    user_pref(“network.protocol-handler.warn-external.mailto”, true);
    user_pref(“”, true);
    user_pref(“network.protocol-handler.warn-external.nntp”, true);
    user_pref(“network.protocol-handler.warn-external.snews”, true);

    With those set, you’ll still be able to use all URI protocols, but get a chance to review the URIs first and cancel anything suspicious.

  • ascii

    External protocol security for FF

    convert to the proper user_pref();

  • Holidays in Egypt

    At least Firefox handles this well

  • parts

    Damont said:

    I’m using the following settings to prevent FF from calling external applications without user interaction:

    user_pref(”network.protocol-handler.external-default”, false);
    user_pref(”network.protocol-handler.external.mailto”, false);
    user_pref(””, false);
    user_pref(”network.protocol-handler.external.nntp”, false);
    user_pref(”network.protocol-handler.external.snews”, false);

    When I click on, e.g., a mailto link, nothing happens, but I can still copy the e-mail adress to my mail client manually . . .

    settings doesn’t work :(