Hi everyone. This is Jonathan from the SWI team in the MSRC. We’ve just released Security Advisory 943521 regarding a vulnerability affecting Windows Server 2003 and Windows XP with Internet Explorer 7 installed. As you have probably noted there’s been a fair amount of discussion on this issue. One of the reasons we are releasing this Advisory is due to increased risk given recent discussions about how this vulnerability could be used in attacks. Another reason is to clear up the confusion we see between the URI issue covered in today’s Advisory and the protocol handler issue we documented in July in this IE Blog. The final reason is we actually contributed to some of the confusion by providing an incorrect set of talking points to Heise. Because these issues look very similar we’re going to have some deep discussion on how Windows handles URIs. To help explain the difference in detail, my co-workers Dave and Chen have helped me put together some information.
Back in June, a number of issues were discussed publicly that involved potential vulnerabilities in protocol handling of 3rd party applications. While we might have been able to make changes in some Windows APIs to block these attacks, doing so could break how the 3rd party applications intended those protocol handlers to function. As a result, we recommend that the owners of the applications themselves address the potential issues since they understand their code the best. For example, application protocol handler authors must take special care to validate every argument which is passed in on the command line. The IE team wrote a good blog entry about validation and who is responsible to for it. You can find this at http://blogs.msdn.com/ie/archive/2007/07/18/enriching-the-web-safely-how-to-create-application-protocol-handlers.aspx.
In late July, another issue was discussed publicly using mailto: and 3rd party applications. This is the vulnerability discussed in the Advisory released today and it is a vulnerability in the way Windows handles URIs. This is not a vulnerability in any specific protocol handler, even though the mailto: protocol handler is used in our example. The examples we have seen involved the mailto: protocol handler being asked to handle URIs containing a % (percent sign). An example of this would be test%../../../../windows/system32/calc.exe”.cmd, which is clearly not a valid email address. When a user clicks a link to a URI, the application showing that link to users decides how it is supposed to be handled. For traditionally “safe” protocols like mailto: or http: applications often just verify the prefix and then choose to call into the Windows shell32 function ShellExecute() to handle it. This has been the case for a number of years. Windows then launches Internet Explorer passing the URI or launches the preferred email client passing the email address, etc. With IE6 installed, ShellExecute() passes the URI to IE which accepts it and inside IE determines it to be invalid. Navigation then fails harmlessly. With Internet Explorer 7 installed, the flow is a bit different. IE7 began to do more validation up front to reject malformed URI’s. When this malformed URI with a % was rejected by IE7, ShellExecute() tries to “fix up” the URI to be usable. During this process, the URI is not safely handled. IE7 rejects the URI, and on Windows Vista ShellExecute() gracefully rejects the URI. That’s not the case on the older versions of Windows like Windows XP and Windows Server 2003 when IE7 is installed.
Since we began investigating this situation in July there’s been more discussion on how to potentially use this in attacks. So to help address overall confusion between these two issues, we’ve released Security Advisory 94351 to alert customers to the risks associated with this issue, and to let folks know we’re working on a security update.
Our plan is to revise our URI handling code within ShellExecute() to be more strict. While our update will help protect all applications from malformed URI’s, application vendors who handle URI’s can also do stricter validation themselves to prevent malicious URI’s from being passed to ShellExecute(). We have seen several vendors introduce additional validation as a way to protect their customers from this issue. We are also working on a KB article to help third party application authors build this type of validation.
While this blog post explains the differences between the two issues reported in June and July we do realize this is a complex issue and we want customers to know that we have been investigating the URI vulnerability covered in this advisory since it was publicly reported in July and will be issuing an update once development and testing is complete.
*This posting is provided “AS IS” with no warranties, and confers no rights.*