IE7/Firefox URI Handling Bug Caused by Windows After All
An exploitable bug discovered earlier this month that was first believed to have been caused by Internet Explorer 7.0, before Mozilla was forced to admit that it afflicted Firefox as well, has apparently been traced back to a Windows API function.
The discovery may have been first revealed through the US-CERT Web site of the Dept. of Homeland Security, which now classifies it as a "Microsoft Windows URI protocol handling vulnerability." The function in question is an old favorite of malware writers: ShellExecute(), which was the subject of a notorious Windows 2000 exploit four years ago.
While Microsoft has yet to issue an official statement or bulletin making this discovery clear, it probably advised US-CERT with regard to its existence. The official government site this morning reads, "We are currently unaware of a practical solution to this problem."
While it awaits such a solution, the finger-pointing over who's responsible may continue to precede any rational discussion over who gets to fix it, as well as the impractical solution of working together to fix it.
The problem, as it now stands, seems to be this: After IE7 is installed on a system, or when a new operating system is installed with IE7 present, the ShellExecute() API function is handled differently. This is the call (or one of the calls) that a Windows application would place when it wishes to launch another application.
When a Web browser receives a URI that contains a resource identifier that obviously isn't http://, it searches the Registry for the external application associated with that identifier. It then launches the application that the Registry reports back, and passes it parameters supplied from inside the URI.
Intentionally malforming the URI is what opens up a browser to the execution of unchecked, remote binary code. Last week, Billy Rios, a senior security consultant for VeriSign , posted on his personal blog that he and a colleague were able to use the exploit to cause remote code execution in Firefox. Once IE7 is installed on a system, Firefox becomes vulnerable, as does Netscape Navigator 9 and the Mozilla open-source browser.
"It's time to take a good look at the registered URI handlers and how browsers interact with those registered URI handlers!" Rios wrote.
This caused Windows security expert and former Microsoft employee Jesper Johannson to take Rios to task for publishing news of the exploit prior to giving Mozilla an opportunity to patch the problem first. His implication there is, of course, that Mozilla is responsible for the problem...a responsibility which its security chief, Window Snyder, ended up assuming last week, with notable regret.
This week, Mozilla's internal bug tracker reports the issue Rios discovered with handling the malformed URI has already been fixed. If that's accurate, another patch may soon be issued, this time disabling Firefox's ability to process a malformed URI that ends up taking a null argument, and thus opening up the browser for remote code execution.
But even if Firefox emerges from this fracas patched -- albeit with its tail tucked between its legs -- will the root of the problem go unchecked? In other words, will the Windows API function that passed the malformed URI to Firefox in the first place be allowed to remain, if both IE7 and Firefox are capable of filtering out the null-argument malformation?
If not, could that bug perhaps be exploited in another way? Or with Microsoft maybe winning this round of finger-wagging, will it go on about its business?