Blocking the Firefox -> IE 0-day

Thor Larholm, unhelpfully, published details on what he claims is a 0-day exploit for Internet Explorer (IE) yesterday. This exploit is actually for Firefox, but Thor exploited it by making IE launch Firefox.

Firefox creates three protocol handlers. A protocol handler is essentially a mapping from an Internet protocol, such as http, to an executable that handles that protocol. For instance, http may be mapped to "C:\PROGRA~1\MOZILL~1\FIREFOX.EXE -url "%1" -requestPending".

Thor claims that a user can go to a web page that invokes a Firefox protocol handler with malicious arguments. In Thor's words: "When Internet Explorer encounters a reference to content inside the FirefoxURL URL scheme it calls ShellExecute with the EXE image path and passes the entire request URI without any input validation." Obviously, the problem here is most definitely not in IE. There is nothing in the protocol handler that informs IE how to perform input validation. IE's only responsibility is to take the parameters that are passed to the protocol and pass them on to the protocol handler, in this case Firefox. Firefox fails to properly validate the parameters, and any fix will have to come from Mozilla, not Microsoft.

A couple of comments on Thor's blog claim to have gotten the exploit to work, but I was unable to do so on either Windows XP SP2 or Vista. The proof of concept that Thor published is full of bugs and does not run at all. The little bit of time I spent fixing it resulted only in disabling the computer by making Firefox open thousands of new tabs. In any case, it seems a far better use of my time to block the exploit altogether than to try to exploit it. That turns out to be simply a matter of deleting the Firefox protocol handlers. To do that on a single computer, run these commands:

reg delete HKCR\FirefoxHTML /f
reg delete HKCR\FirefoxURL /f
reg delete HKCR\Firefox.URL /f

You can of course wrap those in a group policy script, and SMS package, or whatever other mechanism you desire to get them out to many machines. I wrote a couple of posts about how to roll out these kinds of fixes before, such as this one on blocking an ActiveX control vulnerability. The same technique can be used here to roll out this fix to thousands of machines by simply creating a batch file that is deployed as a startup script.

I do not know what these protocol handlers are used for or whether they are essential to the functionality of Firefox or not as I tend not to use Firefox very much. You may, however, want to restore them at some point. To create a backup you can run this command on any machine with Firefox installed:
reg export HKCR\<protocol name> backup<protocol>.reg

That will create a reg script that you can use to reimport the settings once Mozilla produces a patch to fix the problem. The other post I mentioned above shows how to roll that out with Group Policy.

UPDATE 11 July 2007

This may be unrelated - I have not had the time to investigate yet - but yesterday, after I removed the FirefoxHTML protocol handler I started having problems with Outlook. When I clicked on a link in a message I received the "This operation has been canceled due to restrictions in effect on this computer" error message. I realized there was some detritus left in the registry that listed FirefoxHTML as the first protocol handler to use for htm and html files. Deleting those entries solved the problem. I'd like to replicate this before I say for sure that it is related to deleting the protocol handler, but I thought I would throw it out there in case anyone else has seen it.

UPDATE 12 July 2007 - Whose problem is it really?

The debate still seems to be raging about whose problem it is. The Register had an interesting quote by Roger Thompson, CTO of Exploit Prevention Labs, where he reiterated the common mantra that "IE fails to properly validate the input before passing it along". I ask again, what is it that people want IE, or rather, urlmon.dll, which handles this invocation, to validate the input against? IE does NOT support any FirefoxURL protocol, and knows nothing about what a legitimate invocation of that protocol looks like. The argument could be made that IE should not permit quotes to be passed, but why would quotes be illegal in all custom protocols? The protocol handler provides no information to urlmon.dll on what a legitimate request looks like, and therefore, urlmon.dll has no ability to validate the input. In fact, this is documented: "the URL Protocol handler passes the complete URL string to the application registered in the command" [Registering an Application to a URL Protocol, MSDN Library]. It is quite clear really: IE does not validate the URL string, nor does it ever make any promise to do so. It passes the entire string on to the URL Protocol Handler via a call to ShellExecuteEx, if the application is registered using a simple URL protocol handler invocation.

It is clear from the documentation that it is incumbent upon the application to validate the URL string. If the application can accept, and process, dangerous commands through its protocol handler, as Firefox does, it is even more critical that the application take care to validate the URL before processing it. In fact urlmon.dll even provides such a way. To do so, you would use the asynchronous pluggable protocols API, as opposed to a simple URL protocol handler. The asynchronous pluggable protocols API is used to map a COM object implementing certain interfaces as the handler for a protocol, instead of just mapping the protocol to an executable. This results in a programmatic invocation through an API, which provides more security features. One of the interfaces, which the COM object can optionally implement, is the IInternetProtocolInfo::ParseUrl method that permits the handler to see and provide information back to urlmon.dll with respect to the URL. For instance, that method could be used to return information that causes urlmon.dll to consider the URL to be in the Restricted Sites Zone and put extra restrictions on it. Alternatively, the protocol handler can wait until IInternetProtocolRoot::Start gets called, again with the complete URL, and then validate it appropriately at that point. Since the entire URL is passed programmatically in the call to ::start there is no risk that it is interpreted as separate commands, and the handler now gets the ability to validate the input, with the result that multiple invocation problems are not possible. If there is a chance that the URL can contain escaped characters this is a far safer option than the very simple URL protocol handler that Firefox implements currently.

Published Tue, Jul 10 2007 8:55 AM by jesper
Filed under: , ,

Comments

# Richard said on 10 July, 2007 11:57 PM

This is an IE/Windows bug in my view - on Linux/Unix, you would use exec with multiple arguments to safely run a sub-process, even if some arguments had been mangled through this sort of trick.  I'm not sure if such an API exists on Windows, but clearly IE is running Firefox in this case via CMD.EXE, the Windows equivalent of the Linux shell.  

In fact the problem seems much wider - the registry is littered with this sort of command invocation and some of them probably cause security holes like this.

This is one of the oldest tips around for preventing security holes - seems like the IE/Windows programmers aren't aware of it.

# James_A said on 11 July, 2007 02:47 AM

This gets a mention in the SANS ISC diary today.

In the meantime, what version of Firefox do you have, because I can only find TWO protocol handlers (the first two) in the registry, not three. (I have v2.0.0.4)

- James

# Giorgio Maone said on 11 July, 2007 04:02 AM

It's worth noticing that Firefox users with NoScript installed have been already protected both from MacManus/Larholm remote code execution and from Rios "Universal XSS" since June, the 22th, see noscript.net/changelog

More in general, they're protected from chrome privilege escalation gained by opening non-chrome URLs in top-level chrome windows (Larholm's PoC) and from BLOCKED SCRIPT URLs being loaded in externally opened browser shells (Rios' PoC), no matter if attempted through the firefoxurl: handler (like in this specific case) or by other yet unknown means.

# FUD said on 11 July, 2007 08:44 AM

Either you do not understand the problem, or you are being arrogant here. Firefox was chosen as a target because it has the most powerful URL handler. However any other URL handler could be exploited in this way by passing arguments that are not supposed to be passed. The exploit works by breaking out of the quotes, much as a typical SQL injection attack. This is a problem in Internet Explorer, and should be fixed in Internet Explorer.

Mozilla releasing a workaround for their URL handler is a nice courtesy, but it doesn't stop the vulnerability and the exploit could (and probably will) be rewritten to target other URL handlers.

As long as Microsoft says this is somebody else's problem, Internet Explorer users are at (even more) risk.

# jesper said on 11 July, 2007 10:26 AM

Giorgio, good point. There is another way to protect against this issue. Thanks for reminding us.

# CableGuy said on 11 July, 2007 10:31 AM

Thank you Giorgio.  Nice to know, but not a problem on my Linux System :))

# jesper said on 11 July, 2007 11:01 AM

FUD, maybe I do not understand it. How do you suppose IE should validate input to URL handlers? You mention SQL injection attacks, but that is not a very good analogy since in SQL injection attacks the middleware application is what actually takes input, parses it, constructs a query, and sends it on to the database. That is very different in that in the current attack IE is simply a conduit to pass a command to Firefox. A better example would be a buffer overflow in a command line application. You can type "foo.exe bar blaah" on the command line. The app may only expect one parameter and fail spectacularly, but the fault is still with the application, not with the command shell. The command shell has no idea what input the application expects and simply passes on what it receives to the application. Likewise, IE has no knowledge of what Firefox considers a valid URL and will simply pass on what it gets. Firefox needs to validate that it is not doing something untoward with that input.

# dave said on 11 July, 2007 11:58 AM

The 'fix' so to speak is for people not to allow remote invocation of ShellExecute, however you spell it, or whomever you blame it on.  For whoever said that you should just make sure it's 'not doing anything malicious', you should start your own Security/AV company, that's the best idea I've ever heard.

 firefox doesn't have control over how the OS invokes handlers, so it shouldn't provide it the opportunity to assert it's randomness by calling the OS to run this thing at the behest of browser content. (that's right, it's browser content that's able to take over your machine... what's wrong with this picture?)  The only alternative to abolishing this whole handler crap altogether is to make a 'strapping wrapper program that does the filtering and register the handler to that app instead.   Whoever thought it might be a good idea to have this 'feature' in the first place was not quite thinking right.  

I know from my experience with web-app development that any attempts to control the browser or the desktop of the endpoint almost always backfire in some way... HTTP is not meant to be sending instructions to your OS, it's meant to be sending rendering details to your browser (which in a perfect world would render them according to the w3 standards). I'd compare attempts to impelemnt such custom url handlers to thinks like trying to disable the browser's back button from within the web-content. Well what did you expect?  

There are ways to fake it (with things like url handlers), but these holes are ALWAYS going to pop up when you try.  Unless there is a standard browser-to-OS interaction protocol, this kind of tit-for-tat will continue to happen until people stop trying to direct the client host via web content -- and developers keep trying to let them.

# Boris said on 11 July, 2007 01:15 PM

jesper, the point is that IE is failing to pass the URL it should be passing, because it doesn't escape quotes correctly, so quotes in the URL can lead to a situation where IE actually passes multiple command-line arguments, not just a URL.

Firefox's handling is suboptimal, and will be fixed, but IE still has a bug here -- it's not passing the right data to other applications.

# Rob Nicholls said on 11 July, 2007 01:18 PM

This reminded me of the old MHTML vulnerability (MS04-013), that was typically exploited through IE, but was considered a critical vulnerability in Outlook Express. It also reminded me of the more recent MHTML issue (MS07-034) with Vista that was also originally (and still is by Secunia) described as a vulnerability in IE7, but is actually a critical (on Vista) update for Outlook Express and Windows Mail. It's not IE's fault, it's merely used as an attack vector.

I haven't seen anyone else mention that the various PoC floating around appear to be stopped by Vista's Protected Mode (on by default), which prompts the user to confirm that they want to launch Firefox (and subsequent remote command execution). If you don't allow it - and why would you if you were browsing a random web page in IE7? - then you should be okay.

# Labertasche said on 11 July, 2007 02:35 PM

see www.securityfocus.com/.../370959

# Steve Christey said on 11 July, 2007 06:29 PM

Hi Jesper - how is this NOT a classic example of argument injection, as outlined by FUD?  (marc.info is an example).

The exploit includes a leading quotation mark, which IE appears to insert into the command line, which cuts off the "URL" portion of the arguments being passed to firefox.  This seems like a problem that could occur with any arbitrary protocol handler, as implied by the post that Labertasche references.  This could be tested by creating a custom protocol handler and registering it, then seeing if IE correctly escapes/quotes each %1 or related argument before passing it to the receiving program.  I can't do this though, since I'm not an MS developer :)

Now, I can see how this would be difficult if not impossible for IE to fix for arbitrary handlers - or any technology that would use external "templates" for modifying command lines (wouldn't surprise me if other browsers have similar problems) - but that doesn't make it the called application's fault that it's being called with switches that the calling application didn't intend.

# jesper said on 12 July, 2007 04:07 AM

Steve, nice thoughtful comment that I just saw (been getting a lot of mail on this one). I agree, this is really difficult for IE to handle. However, the protocol handler can do it, in a couple of ways, including by not using the simple invocation method that FF is using. See my latest update, above.

Now, one could argue that it would be nice if IE put some more restrictions on what it passed to a protocol handler, but not only is it difficult for IE to make decisions regarding what third-party plug-ins get to see, to put those restrictions on third party developers after the fact is even worse. It also is quite clear in the documentation that IE, or urlmon.dll rather, will pass the entire string on to the application. If the handles will parse parameters that can cause problems, then the invocation method used by FF is unsafe.

BTW, you don't need to be much of a Windows developer to write a protocol handler like the one FF is using. All you need is:

#include <stdio.h>

int main(int argc, char* argv[])

{

   // The URL is in argv

   printf("\nThere are %d arguments in the URL\n", argc);

   for(int i=0;i<argc;i++)

   {

       printf("\nArgument %d:\t%s",i,argvIdea);

   }

   printf("\n");

   char c;

   c = getc(stdin);

}

Then you register the app as the protocol handler:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\firefoxURL]

@="URL:FirefoxURL Protocol"

"URL Protocol"=""

[HKEY_CLASSES_ROOT\firefoxURL\DefaultIcon]

@="cmd.exe"

[HKEY_CLASSES_ROOT\firefoxURL\shell]

[HKEY_CLASSES_ROOT\firefoxURL\shell\open]

[HKEY_CLASSES_ROOT\firefoxURL\shell\open\command]

@="\"c:\\test.exe\" \"%1\""

And, out comes what urlmon is passing in:

There are 4 arguments in the URL

Argument 0:     c:\test.exe

Argument 1:     firefoxurl://larholm.com

Argument 2:     -chrome

Argument 3:     BLOCKED SCRIPTC=Components.classes;I=Components.interfaces;file=C['

@mozilla.org/file/local;1'].createInstance(I.nsILocalFile);file.initWithPath('C:

'+String.fromCharCode(92)+String.fromCharCode(92)+'Windows'+String.fromCharCode(

92)+String.fromCharCode(92)+'System32'+String.fromCharCode(92)+String.fromCharCo

de(92)+'cmd.exe');process=C['@mozilla.org/process/util;1'].createInstance(I.nsIP

rocess);process.init(file);process.run(true,['/k echo hello from larholm.com'],1

);alert(process)

Firefox gets three arguments, instead of the one that it is expecting. It then goes ahead and actually processes all of them, and therein lies the problem. There are a couple of options to fix this. The simplest is probablynto change the protocol handler to invoke "firefox.exe -protocolhandler" "%1". Then, in main, before you do anything else, do:

if( !(strcmp(argv[1],"-protocolhandler")) && (argc > 3))

   exit(-1);

In other words, if you get more arguments than you should for a protocol handler, stop executing it. Alternatively, put the protocol handler in a different executable from the main one that handles only a single argument and exits if it gets anything else. Any protocol handler that parses the passed in URL and executes additional command line arguments would be vulnerable to this problem.

# Dave said on 12 July, 2007 11:54 AM

> Now, one could argue that it would be nice if IE put some more restrictions on what it passed to a protocol handler, but not only is it difficult for IE to make decisions regarding what third-party plug-ins get to see,

If we assume that the URL handling mechanism is supposed to be used for handling URLs, then applying URL escaping would seem to be the obvious choice, no?

> to put those restrictions on third party developers after the fact is even worse.

Yes, that's true.  Hopefully applications that handle URLs support the proper escaping methods, but that's probably wishful thinking.

> The simplest is probablynto change the protocol handler to invoke "firefox.exe -protocolhandler" "%1".

That's more or less what Mozilla's workaround does: bonsai.mozilla.org/cvsquery.cgi

# Alun Jones said on 12 July, 2007 08:02 PM

I've got to agree with Jesper here - IE laid down the parameter-passing method, and given that there's only one parameter ("the rest of the URL after the scheme and the colon"), there's not much point doing any quoting, encoding, or anything - as long as the end of the parameter is uniquely defined (and if not, what has the attacker done?)

Remember, too, that the parameter parsing mechanism used here is going to be solely dependent on the language and API the protocol handler uses. It's only because most people use C / C++ / etc that we're used to seeing multiple arguments separated by spaces, tabs, etc. What the OS passes in to the executable is the entire command line from start to finish in one long string.

Any other structure that you believe is present in the command line is imposed by the runtime library that the executable starts up before it calls the "main()" or other first developer-level function.

Yes, because the source is a URL, using URL encoding would make sense as well, but that would only make a significant difference if using that encoding prevented ambiguity in parsing the URL. In this case, because there's no special character in the command-line, there's no ambiguity in parsing - every byte of the command-line past the executable's name is _the_ only parameter to the protocol handler.

# Charles Burnaford said on 15 July, 2007 10:35 AM

There is a way for IE to filter this attack out.  It should not allow the opening of an http: URL by any other program other than itself.  

Of course this would require that the program be apprised of the various alternate browsers.   I know that this kind of thing is done with SSL CA certificates.

# Harry Johnston said on 18 July, 2007 07:39 PM

OK; the fact that this behavior is documented puts some of the blame on Mozilla.  Fair enough.  (The behavior is still incorrect, so I'm still going to put most of the blame on Microsoft.)

In particular note that your statement "The argument could be made that IE should not permit quotes to be passed, but why would quotes be illegal in all custom protocols?" is incorrect.

Quotes are illegal in all custom protocols, because they're illegal in the definition of a URL.  No URL may contain a quote mark.  If a custom protocol uses quote marks, that protocol is in violation of the standards.  (STD66.)

QED. :-)

# inkredibl said on 19 July, 2007 06:08 AM

Blame Microsoft for not following standards (nothing new here)...

RFC 1738:

only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used _unencoded_ within a URL.

Not sure if this is Windows or IE, but it sure as hell is Microsoft's fault! Of course Firefox _can_ fix that in one way or another, but that doesn't mean Firefox is guilty. Any other URL handler can be exploited like this and Firefox fix won't affect others, only Microsoft could fix it once and for all, but they won't - why bother...

# Keith said on 19 July, 2007 07:51 PM

This was a very fruitful conversation.  I came off MozillZine to here not knowing exactly what to think.  So, in summary, it's not Microsoft's fault because Firefox is using a feature in a more advanced way than it's designed to be?  Well, I use SeaMonkey in Linux, but still it's good to get things cleared up.

Of course, it is possible to implement URLs correctly (for general idiot-proofing) or make the function's limitations more explicit.  I'm not going to be a Microsoft apologist or a Firefox fanboy here, but I'm just saying.

# Fernando said on 20 July, 2007 01:38 AM

@inkredibl

RFC 1738 has long been superseeded. Try RFC 3986.

# Labertasche said on 20 July, 2007 11:05 AM

@jesper

How does that differ from a SQL injection? The "middleware" application (IE) takes input (the URL), parses it, constructs a query, and sends it on to the shell.

# jesper said on 20 July, 2007 12:21 PM

I think this is very different from a SQL injection bug. In the SQL injection case it is the middleware that parses input and constructs a command. It knows all about what is legal and what is not, while the database knows nothing about what is legal.

In the case of the Firefox input validation failure, urlmon.dll is simply passing on a string it received as a command. It does not know what the called application considers legal and has no way to find out. It could potentially attempt to make the URL conform to a legal URL, but as urlmon.dll does no processing on the URL at all, it really ought to be up to the application that processes it to make sure it conforms to whatever conventions and rules that application expects. You cannot blame a web server for a SQL injection bug as it merely passes the input data onto the middleware application. It is the same in the case at hand; urlmon is simply passing on the input data to the protocol handler.

# Labertasche said on 21 July, 2007 01:39 AM

OK if neither IE nor urlmon.dll reads the regkey, substitutes the %1 and passes this constructed command to the shell, which part does it?

"It does not know what the called application considers legal and has no way to find out."

Since the request is passed to shell in the end and you know how it handles quote characters, there is no need know what the target considers legal.

"It could potentially attempt to make the URL conform to a legal URL, but as urlmon.dll does no processing on the URL at all, it really ought to be up to the application that processes it to make sure it conforms to whatever conventions and rules that application expects."

Since the encoding rules are the same for every URI the caller knows what the target expects. Also the caller knows exactly what is part of the URI while the target needs to reconstruct it in this case.

# Harry Johnston said on 22 July, 2007 01:20 PM

Labertasche:- the request is (almost certainly) handed to the Windows API, not to the shell; further, the shell doesn't process quote marks at all when passing a command line to an external executable.

(However, the legal characters are defined by STD66 so IE/urlmon should have no difficulty in this regard.)

# Alun Jones said on 22 July, 2007 03:38 PM

I think Labertasche is confused by Jesper's wording. Yes, urlmon.dll processes the registry keys to figure out which protocol handler to call, builds the command line, and executes the handler, but as Jesper says, it does no processing on the URL - it reads it in, and it hands it along, unprocessed - unchanged.

As it turns out, the shell does not handle quote characters in this case. It is the runtime library for the particular language which does.

If you choose C or C++ as your language of choice, for instance, the command line string as a whole is parsed in the CRT library routine parse_cmdline(), which (if you have Visual Studio installed) is in %ProgramFiles%\Microsoft Visual Studio 8\VC\crt\src\stdargv.c

If you use assembler, or write your program for Win32 (with a start function of WinMain instead of main), you'll be given the command line as a single string from first character entered to the final character provided by your caller.

Double-quote processing is a feature of C and C++, NOT of the Windows executable calling mechanism.

To put it another way, double quotes are only special to Firefox because Firefox's programmers chose to treat them specially. As such, it's their responsibility to ensure that they are handled correctly when faced with data provided by untrusted third parties.

# Harry Johnston said on 23 July, 2007 10:28 PM

Seems it's slightly more complicated than at first it seemed.  The relevant Microsoft documentation

<msdn2.microsoft.com/.../aa767914.aspx>

requires URIs to be decoded before being passed to the protocol handlers.  That is, you should be able to exploit the reported vulnerability without using illegal URIs.

This changes things.  It means that IE (and other browsers) can't fix the problem without potentially breaking third-party protocol handlers that depend on the documented behavior.

Technically, it also means Jesper (and Microsoft) are correct; the bug is in the software registering the protocol handler (Firefox in this case) not in the software calling it.

However, I'm still going to blame Microsoft, because frankly, passing URIs between applications in decoded form was a really really dumb idea.  Very few application developers would have spotted this particular trap.

# driver said on 15 July, 2008 06:48 AM

Hi,

jesper, the point is that IE is failing to pass the URL it should be passing, because it doesn't escape quotes correctly, so quotes in the URL can lead to a situation where IE actually passes multiple command-line arguments, not just a URL.

Firefox's handling is suboptimal, and will be fixed, but IE still has a bug here -- it's not passing the right data to other applications.

# Poartoem said on 01 November, 2008 02:34 PM

Since the request is passed to shell in the end and you know how it handles quote characters, there is no need know what the target considers legal.