Blocking the Firefox -> IE 0-day

re: Blocking the Firefox -> IE 0-day

Poartoem — Sat, 01 Nov 2008 19:34:12 GMT

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.

re: Blocking the Firefox -> IE 0-day

driver — Tue, 15 Jul 2008 11:48:58 GMT

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.

re: Blocking the Firefox -> IE 0-day

Harry Johnston — Tue, 24 Jul 2007 03:28:29 GMT

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.

re: Blocking the Firefox -> IE 0-day

Alun Jones — Sun, 22 Jul 2007 20:38:02 GMT

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.

re: Blocking the Firefox -> IE 0-day

Harry Johnston — Sun, 22 Jul 2007 18:20:51 GMT

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.)

re: Blocking the Firefox -> IE 0-day

Labertasche — Sat, 21 Jul 2007 06:39:26 GMT

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.

re: Blocking the Firefox -> IE 0-day

jesper — Fri, 20 Jul 2007 17:21:42 GMT

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.

re: Blocking the Firefox -> IE 0-day

Labertasche — Fri, 20 Jul 2007 16:05:44 GMT

@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.

re: Blocking the Firefox -> IE 0-day

Fernando — Fri, 20 Jul 2007 06:38:55 GMT

@inkredibl

RFC 1738 has long been superseeded. Try RFC 3986.

re: Blocking the Firefox -> IE 0-day

Keith — Fri, 20 Jul 2007 00:51:55 GMT

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.

re: Blocking the Firefox -> IE 0-day

inkredibl — Thu, 19 Jul 2007 11:08:39 GMT

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...

re: Blocking the Firefox -> IE 0-day

Harry Johnston — Thu, 19 Jul 2007 00:39:32 GMT

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. :-)

re: Blocking the Firefox -> IE 0-day

Charles Burnaford — Sun, 15 Jul 2007 15:35:00 GMT

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.

re: Blocking the Firefox -> IE 0-day

Alun Jones — Fri, 13 Jul 2007 01:02:13 GMT

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.

re: Blocking the Firefox -> IE 0-day

Dave — Thu, 12 Jul 2007 16:54:07 GMT

> 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