[ NOTE: See update below on confusion over whether this is an IE or a Firefox vulnerability ]
Microsoft's Internet Explorer browser is vulnerable to a protocol handler command-injection vulnerability that could allow malicious code attacks with limited user action.
[It] allows you to specify arbitrary arguments to the process responsible for handling URL protocols.
The bug could effectively allow remote attackers to pass and execute arbitrary commands and arguments through the 'firefox.exe' process.
A successful attack requires that the user is tricked into clicking on a link on a rigged Web site or in an HTML e-mail.
Researchers at Symantec have detailed the following attack scenarios:
- An attacker constructs malicious HTML to influence command-line parameters for the external application that will run when a URI is loaded.
- The attacker embeds the malicious HTML code in a webpage or sends it through HTML email.
The malicious code may be automatically loaded when the page or HTML email is rendered. User interaction is required as they must follow a link to a malicious site or open a malicious email.
Click here for Larholm's proof-of-concept which demonstrates the vulnerability.
[ UPDATE: July 10, 2007 @ 12:19 PM ] Security researchers are in disagreement over whether this is a vulnerability in IE or Firefox. Larholm and Symantec's DeepSight researchers insist it's a bug in the way IE validates certain inputs but Secunia's research team claims this is a Firefox issue.
Secunia CTO Thomas Kristensen sent me the following via e-mail:
To avoid any possible confusion, I just wanted to let you know that Secunia - as always - have tested and analysed the alleged zero-day in IE that was reported earlier today.
This is in fact NOT an IE issue - it is a Firefox issue.
Since Firefox 188.8.131.52, a new URI handler was registered on Windows systems to allow websites to force launching Firefox if the "firefoxurl://" URI was called (like ftp://, http://, or similar would call other applications).
However, the way in which the URI handler was registered by Firefox causes any parameter to be passed from IE (or another application) to Firefox when firefoxurl:// is activated. Due to the implementation of the "-chrome" parameter, it became possible to inject code that would be executed within Firefox.
Registering a URI handler must be done with care, since Windows does not have any proper way of knowing what kind of input potentially could be dangerous for an application (i.e. how should Windows know that the string "-chrome" could be dangerous for Firefox?).
Windows will only filter certain non-application specific meta characters; anything that is specific for the application called by the URI handler must be handled by the application itself.
Improper usage of URI handlers and parameters supplied via URIs has historically caused problems for many vendors including, Microsoft, Apple, Mozilla, certain Linux projects, Opera, and others.
I've pinged Microsoft, Larholm and the folks at Mozilla to try to get to the bottom of this. Will update this post as necessary.
[ UPDATE: July 10, 2007 @ 2:08 PM ] Mozilla security chief Window Snyder comments:
"We are aware of this issue and we are developing a fix. Mozilla is committed to delivering the safest online experience for its users."
This from the Microsoft Security Response Center:
Microsoft has thoroughly investigated the claim of a vulnerability in Internet Explorer and found that this is not a vulnerability in a Microsoft product.
Still waiting for word from Larholm...
Larholm's response, sent to me via e-mail:
Internet Explorer and Firefox are both to blame. Firefox could have registered their URL protocol handler differently, for example with pure DDE, but IE is still to blame for not escaping " (quote) characters.
The latter can be evidenced by the fact that you can inject arbitrary arguments to a wide range of other URL protocol handler applications, such as irc:// (mIRC), aim:// (AOL Instant Messenger), hcp:// (Windows HelpCenter) and mms:// (Windows Media Player) to name just a few.
This is a generic flaw in Internet Explorer that has been left unpatched since at least 2004.