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.