X
Business

IE-to-Firefox flaw debate rages: Ex-Microsoft security strategist weighs in

While Microsoft has declined to comment on the IE-to-Firefox flaw drama (beyond an "it's not our fault" statement), a former security strategist is coming to the company's defense, arguing that there's no real way for Internet Explorer to validate the code being passed to Firefox.
Written by Ryan Naraine, Contributor
jesperjohansson.jpg
While Microsoft has declined to comment on the IE-to-Firefox flaw drama (beyond an "it's not our fault" statement), a former security strategist is coming to the company's defense, arguing that there's no real way for Internet Explorer to validate the code being passed to Firefox.

Jesper Johansson (left), a Windows internals guru who now works at Amazon.com, has been following the issue closely on his personal blog (see update below) and insists that the documentation makes it clear that IE never makes a promise to validate the URL string being passed to third-party applications.

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.

Johansson says it's clear from the documentation that the responsibility rests with 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," he argues.

However, in the comments section, MITRE Corp.'s security engineer Steve Christy suggests a way for IE to block the attack vector:

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

In response, Johansson said it would be nice for IE to put some more restrictions on what it passed to a protocol handler, but make it clear that it is difficult for IE to make decisions regarding what third-party plug-ins get to see. It's even worse to do it after the fact, he said.

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.

While the debate rages, I think Microsoft should bear in mind that the people at risk here are Windows users. A hands-off approach doesn't change that.

Editorial standards