IE 7 Cross-Browser Scripting Exploit Goes Zero Day
- By Stephen Swoyer
- July 11, 2007
Since its debut, Internet Explorer (IE) 7.0 has arguably established itself as Microsoft Corp.'s most secure Web browser to date. To be sure, Redmond has dutifully included IE 7.0 patches
in its Internet Explorer patch roll-ups -- but at the very least, Microsoft's newest IE flavor hasn't fallen prey to any of the blockbuster exploits that have so bedeviled Internet Explorer in the past.
Just this week, however, a security researcher alerted IE users (and Microsoft itself) to a new input validation vulnerability in IE 7.0.
Thor Larholm, a Danish security consultant and entrepreneur, yesterday published details -- complete with exploit code -- about the IE 7.0 flaw, comparing it to a similar issue that he discovered in Apple Inc.'s Safari 3.0 browser beta.
There's a caveat. For IE to actually be vulnerable, the Firefox browser from Mozilla must also be installed. That's because Firefox registers a URL handler called "FirefoxURL," which basically gives it -- and other applications -- a means to invoke Firefox from the Windows shell.
The problem, Larholm says, is that when IE encounters the FirefoxURL handler, it calls ShellExecute with the EXE image path and processes the entire request without any input validation. In other words, he points out, IE will pass any command to ShellExecute -- even potentially unsafe or malicious instructions.
you can specify process arguments with the nsIProcess interface found in Mozilla."
Larholm isn't the first researcher to note some of the shortcomings of the FirefoxURL handler. Security researchers Billy Rios, Nate Mcfeters and Raghav Dube had previously published proof-of-concept code for a cross-browser scripting exploit. Because
Nor is IE the only browser vulnerable to this exploit; theoretically, any browser that runs under Windows is susceptible.
So, is the flaw an IE or Firefox flaw? To a degree, both programs are at fault, Larholm said.
"Firefox is the current attack vector ... but IE should still be able to safely launch external applications safely," he wrote in response to user comments on his blog.
Larholm also noted that other URL handlers -- such as those for Internet relay chat (irc://) and AOL Instant Messenger
(aim://) could be vulnerable, too.
"Internet Explorer doesn't filter the input for the irc:// or aim:// URL protocol handlers either. The exploitability on those depend on what arguments each application accepts,"
Larholm provides a working proof-of-concept of the exploit here.
Stephen Swoyer is a contributing editor for Enterprise Systems. He can be reached at [email protected]