Hi everyone,

Bill Sisk here.  This week we became aware of publicly disclosed exploit code being used in limited attacks on customers.  This change in the threat landscape has prompted us to update last week’s Security Advisory 943521 and triggered our Software Security Incident Response Plan (SSIRP).  

Third party applications are currently being used as the vector for attack and customers who have applied the security updates available from these vendors are currently protected.  However, because the vulnerability mentioned in this advisory is in the Microsoft Windows ShellExecute function, these third party updates do not resolve the vulnerability – they just close an attack vector.

As part of our SSIRP process we currently have teams worldwide who are working around the clock to develop an update of appropriate quality for broad distribution. Because ShellExecute is a core part of Windows, our development and testing teams are taking extra care to minimize application compatibility issues. 

To help protect yourself during the interim we continue to recommend that you should always exercise extreme caution when opening unsolicited attachments from both known and unknown sources and/or visiting untrusted websites.  This is absolutely one of the most effective ways to help protect yourself from a variety of threats on the Internet today.  

As always, we will be working with our Microsoft Security Response Alliance partners throughout this incident to provide them information on the vulnerability and attacks we see to help better protect our mutual customers.

Again, while we have seen active exploit, these attacks are fairly limited at this time but we wanted to let you know we are working around the clock to monitor the situation and get an update out to help protect you from these malicious attacks as soon as possible.  As always we will be keeping you updated through the MSRC Blog.

Bill

*This posting is provided "AS IS" with no warranties, and confers no rights.*

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 3^rd 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 3^rd 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 3^rd 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.

Since this is my first post, I suppose a quick introduction is in order. I’m Bill Sisk, a member of the Security Response Communications Team. My team works to provide communications around security response issues to our customer through MSRC Blogs and other outreach vehicles.

As part of that I wanted to let people know that we just posted Microsoft Security Advisory 943521, which gives additional information about a vulnerability in the way Microsoft Windows XP SP2 and Windows 2003 SP1 and SP2 handle URI’s when only Internet Explorer 7 installed.  Windows Vista is not affected by this vulnerability.  At this time, we are not aware of attacks attempting to use the reported vulnerability, but we are tracking this issue through our Software Security Incident Response Process and working on a security update to resolve it.

Additionally in a blog entry that will follow this Jonathan Ness of the SWI Team will provide some additional details around this vulnerability.

As always, we'll continue to monitor the situation and provide updates to the advisory and MSRC Blog should the situation change or we become aware of new information.

Thanks.

Bill

*This posting is provided "AS IS" with no warranties, and confers no rights.* 

Hello,

This is Christopher Budd. I wanted to let you know that we’ve just posted our Advance Notification for next week’s bulletin release on Tuesday October 9, 2007 at or around 10 a.m. Pacific Time.

A reminder that the information we post is intended to help with your planning for next week, but because it is preliminary information it is subject to change.

As part of our regularly scheduled bulletin release, we’re currently planning to release seven security bulletins:

·         Five Microsoft Security Bulletin affecting Microsoft Windows with a Maximum Severity rating of Critical. Some of these updates will require a restart and will be detectable using the Microsoft Baseline Security Analyzer and the Enterprise Scan Tool. 

·         One Microsoft Security Bulletin affecting Microsoft Office with a Maximum Severity rating of Critical. These updates will not require a restart and will be detectable using the Microsoft Baseline Security Analyzer.

·         One Microsoft Security Bulletin affecting Microsoft Windows and Microsoft Office with a Maximum Severity rating of Important. These updates may require a restart and will be detectable using the Microsoft Baseline Security Analyzer.  

We are also planning to release an update to the Microsoft Windows Malicious Software Removal Tool as we do each month.

Finally, we are planning to release three high-priority, non-security updates on Microsoft Update and one on Windows Update.

Finally, we’ll be holding the October Edition of the monthly security bulletin webcast on Wednesday October 10, 2007 at 11 a.m. Pacific Time.  Mike Reavey and I will review this month’s release and take your questions live on-air with answers from our panel of experts. Don’t forget if you can’t make the live webcast that you can listen to it on-demand as well.

You can register for the webcast here:

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032344692&EventCategory=4&culture=en-US&CountryCode=US

Thanks,

Christopher

*This posting is provided "AS IS" with no warranties, and confers no rights.*