Theres still no consensus regarding whether the zero-day vulnerability that security researcher Thor Larholm found is on Internet Explorer or on Firefox. But more to the point, there is a way to block the exploit, which otherwise could lead to remote system hijacking.
According to Microsoft Security Program Manager Jesper Johansson, blocking the exploit boils down to deleting Firefox protocol handlers. To do so on a single computer, he said, requires running these commands:
reg delete HKCRFirefoxHTML /f
reg delete HKCRFirefoxURL /f
reg delete HKCRFirefox.URL /f
One way to kill the protocol handlers on multiple machines is to group policy script and SMS packages, he said. Rolling the fix out to thousands of machines can be done by creating a batch file deployed as a startup script.
To enable restoration of the protocol handlers, Johansson recommended running this command on any machine with Firefox installed:
reg export HKCR backup.reg
“That will create a reg script that you can use to re-import the settings once Mozilla produces a patch to fix the problem,” he said.
Larholm initially blamed the vulnerability on an input validation flaw in Internet Explorer that allows users to specify arbitrary arguments to the process responsible for handling URL protocols. Its the same type of input validation vulnerability that Larholm discovered in the Safari 3 beta, he said.
/zimages/4/28571.gifTo read more about Thor Larholms initial discovery of the zero-day vulnerability,click here.
At this point, partisans of one browser are pointing fingers at the other, while Larholm maintains an even-handed stance.
“Its partly a fault in both,” Larholm conceded after revealing details of what he initially called the IE zero-day vulnerability on July 10. “Firefox shouldnt have allowed [IE to pass] malicious code, but [IE] shouldnt allow the quote passed in the input to the command line [too].”
Others continue wanting to assign blame squarely in one camp or the other.
“Bollocks,” wrote Michael Mattsson, a responder on Larholms blog,. “It should never be the responsibility of the calling program. It is the target app (in this case Firefox) that bears responsibility of ensuring that all passed params include proper escape codes, prevent buffer overruns, etc. How could IE (or other calling app) know what code/params/etc. that a separate [third party] may have problems with?”
Mattsson and others of the “its a Firefox flaw” ilk are pointing out that there are many other ways that the vulnerability can be exposed over and above using IE.
“Most programs that can launch a URI could expose this flaw in Firefox,” Mattson added.
One counterargument from the “blame IE” crowd is that IE could well have known how to format the “FirefoxURL” parameter correctly. Jonathan Landis pointed out, in another response on Larholms blog, that rather it looks like IE bungles all external file handler launches, and that the current flaw is just one example of this incorrect handling and its effect on Firefox.
“Blaming Firefox here for not catching the malicious script is like blaming the SQL server for not catching a malicious query,” Landis wrote. “The calling convention is clear—escape the quotes or your request wont get processed as intended and may cause undesired results.”
For his part, Microsofts Johansson said in his blog that the problem is “obviously” in Firefox, given that theres nothing in IEs protocol handler that tells it how to perform input validation.
“IEs 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,” he said.
The back-and-forthing continues.
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.