IE 7 Cross-Browser Scripting Exploit Goes Zero Day
Just this week, a security researcher alerted Internet Explorer users (and Microsoft itself) to a new input validation vulnerability in IE 7.0.
- 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 Internet Explorer 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 Internet Explorer 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.
So, is the flaw an IE or Firefix flaw? To a degree, both programs are at fault, Larholm says: "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," he indicates.
Larholm provides a working proof-of-concept of the exploit here.
Stephen Swoyer is a Nashville, TN-based freelance journalist who writes about technology.