Security Advisory 943521just 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.
Continue At Source
Send via e-mail | Submit to Digg | Add to Live Favorites
http://feeds.feedburner.com/~r/binkdotnu/~3/168148437/security-advisory-943521.aspx
