The information has been provided by Greg MacManus.
The original article can be found at: http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=565
This vulnerability is due to interaction between programs. The most commonly used Microsoft Windows URL protocol handling code doesn't provide a way for the URI handling application to distinguish the end of one argument from the start of another.
The problem is caused by the fact that browsers do not pct-encode certain characters in some URIs, which does not comply with the behavior that RFC3986 (also known as IETF STD 66) requires. As a result, a specially constructed link could be interpreted as multiple arguments by a URI protocol handler.
Exploitation of this vulnerability allows an attacker to execute arbitrary commands as the current user. To exploit this vulnerability, an attacker must persuade their target into visiting a website containing a maliciously constructed link.
This vulnerability does not allow for code execution directly. Instead it relies on the URI handling application to contain methods by which code execution is obtainable. Even if no such methods exist, it may still be possible to pass additional command line parameters that execute unintended actions.
The target user must have an application installed which accepts command line options after the URI passed to the protocol handler, such as versions of Firefox before 220.127.116.11. When opening a URL, typically it is started with a command line such as:
[path/to/handler.exe] -url "%1"
In this case, the "%1" is replaced with the source URL. If the URL contains a double-quote character followed by a space, the quoting will be closed, and the rest of the source URL will be treated as new arguments.
On June 14, 2007 Microsoft stated to us that this behavior is documented, referencing (http://msdn2.microsoft.com/en-us/library/aa767914.aspx). At this time, the document contained an example handler for the 'note:' protocol to explain how to create URL handlers. It contained this type of vulnerability. The documentation did state that the "handler passes the complete URL string to the application", but did not explicitly state that multiple arguments could be injected, and that the URI would be percent-decoded. If the example handler from the documentation was added, calc.exe would be launched when opening a page that contained
the following HTML:
<iframe src='note:"|calc.exe '>
As this document was written to inform developers how to construct these handlers, it is very likely many applications which implement URL handlers are also affected. Microsoft has updated the document around July 17, 2007. It has replaced the 'note:' handler with a new handler example, 'alert:', which launches a sample application that lists the command line arguments the URL handler passed to it.
iDefense has confirmed the existence of this vulnerability using the following products on the Windows XP SP2 operating system.
* Mozilla Organization; Firefox and Thunderbird 18.104.22.168
* Microsoft Corp.; Internet Explorer 7
Previous versions of each application may also be affected. Other applications which access websites with an embedded browser control are also affected.
While this vulnerability is due to various applications incorrectly escaping URIs, the way code execution occurs is via helper
The following keys are examples of URL Protocol handlers. Removing the 'shell' sub-keys of dangerous URI handlers will reduce exposure to this class of vulnerability. For example:
Some functionality will be reduced after removing these keys. Certain applications regenerate their protocol handlers automatically; consider applying a 'Deny' to 'Everyone' to the handler key (the key above without the '\shell' component). To find other protocol handlers, search the registry for the value name "URL Protocol".
Turning off the rendering of HTML within mail applications will mitigate exposure to this type of vulnerability via an e-mail attack. In Thunderbird, under the 'View' menu, select 'Message Body As' and select 'Plain Text'.
Microsoft stated this is "documented behavior" in June 2007, but in mid-July 2007 updated the contents of the page describing how to construct a URL handler. They now include a security note that this type of exposure may occur, and describe in detail the steps taken. A link to this page is shown in the sources and referenced in the analysis.
Mozilla has changed its handling of URLs in Firefox 22.214.171.124. Thunderbird 126.96.36.199 is not yet available for download, but will reportedly also change its handling.
06/13/2007 - Initial vendor notification
06/13/2007 - Initial Microsoft response
06/13/2007 - Initial Mozilla response
06/14/2007 - Microsoft states defined behavior
07/17/2007 - Microsoft updates MSDN article
07/17/2007 - Mozilla releases Firefox 188.8.131.52
07/19/2007 - Public disclosure