Hello everyone,

This is Christopher Budd. We’ve not seen any new developments in the DNS situation but I wanted to go ahead and take a minute to recap the current situation so everyone is up-to-date.

Also, I wanted to call out some information for your deployment planning to help expedite the deployment of the security update for this issue when we release it.

Recap of Current Situation

With the ongoing development and testing work from our teams on the issue, we are increasingly confident that we will have an update of appropriate quality for broad distribution in time for the May 8, 2007 monthly bulletin release. This will enable us and our customers to release and deploy the update as part of the regular monthly update process. However, as I’ve mentioned before, because testing is ongoing and we are constantly evaluating the situation, this could change. If it does, we will let you know through this weblog.

Also, our ongoing monitoring and work with our Microsoft Security Response Alliance (MSRA) partners shows no new malicious software attempting to exploit this vulnerability, and the information we posted about malicious software attempting to exploit this vulnerability last Thursday remains current. Also, just like we noted on Sunday, indications are that attacks are still not widespread.

Most importantly, we know from our Customer Service and Support organization that customers are following our guidance and protecting themselves by deploying the workarounds in our security advisory. We continue to encourage customers to protect themselves by deploying the workarounds and ensuring their security products are up-to-date while we continue our ongoing work on the security update.

Information for your deployment

As this is an update for Windows, this update will be supported by the usual detection and deployment tools for security updates for Windows.

That said, I wanted to call attention to some things that you might want to consider when thinking about the deployment of the update when it’s released. Most of this is recapping information we’ve mentioned at other points in time, but I wanted to reiterate it now. Hopefully this can help you to address any issues that could slow your deployment in advance of the update’s release.

First, since support for the legacy WSUSSCAN.CAB expired in March 2007, you need to ensure that your detection and deployment tools now support the new WSUSSCN2.CAB file. There will be no support for the security update for this issue in the old WSUSSCAN.CAB architecture.

If you use MBSA 2.0 in offline-scan mode, you will need to use MBSA 2.0.1. If you use the SMS 2003 Inventory Tool for Microsoft Updates (ITMU), you need to ensure you’re using version 3 of that tool.

Next, a reminder that as part of our standard Microsoft Support Lifecycle, support for Windows Server 2003 Service Pack 0 (RTM) expired on April 10, 2007 with the April monthly bulletin release. Windows Server 2003 Service Pack 1 and Windows Server 2003 Service Pack 2 are the currently supported versions. You can get more information on the Microsoft Support Lifecycle dates for your planning at: http://www.microsoft.com/lifecycle.

I also wanted to remind you that when the security update is released it will NOT undo any of the workarounds that you may have applied. You should include a plan to undo the workarounds you implemented during your deployment. We have information on how to undo the registry key workaround in our security advisory.

Finally, at this time, we believe that this security update will require a reboot. That information may change, but I wanted to include it now as I know that is important for your planning.

We’ll continue working on this issue and are monitoring the situation constantly until we release the update. And, as we have new information, we will let you know through our security advisory and this weblog.

Thanks.

Christopher

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

Hi everyone this is Adrian Stone.

One question that I still get regularly on the .ANI case that was part of the MS07-017 bulletin by many people outside of Microsoft is “After all the work Microsoft did leveraging the Security Development Lifecycle, why didn’t it help catch this vulnerability in Windows Vista?” Honestly, that is a fair question and one I asked myself during the investigation, as I was the program manager responsible for the case. I decided to walk down the hall from my office to ask Michael Howard myself. 

Michael works on the Security Development Lifecycle (SDL) right along side the MSRC. The SDL group is a bunch of talented people who track down security issues we identify in our investigation and work to ensure that the knowledge gained from an issue goes toward making our future products more secure. The MSRC and the SDL teams work together on all the bulletins we release.

Something important to remember, and if you have ever had a chance to listen to Michael speak he often mentions, is that the Microsoft Security Response Center or any planned security response to an issue doesn’t necessarily mean that SDL is ineffective or not working. Actually, having a security response plan and the existence of the Microsoft Security Response Center is part of a healthy and robust implementation of SDL. No matter how good an implementation of an SDL is, the software will always be developed to be the most secure it can be for that point in time. Essentially, the threat landscape may change or transform in ways that one could not have accounted for and thus it will always be necessary to know which parts of the organization need to be mobilized to address the concerns and release an update.

Michael and others responsible for SDL recently launched the SDL blog and have an interesting post about the .ANI case that I think can help answer some of the questions you have posed to me about the matter. I can assure you that hearing from the SDL experts will be better than my attempts to explain the depth and comprehensiveness of the work they do. In any case, I encourage you to check out their blog.

Thanks,

-A

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

Hello everyone,

This is Christopher Budd. I wanted to take a moment and provide a brief update on the situation from our work over the weekend.

As of tonight, the situation remains unchanged. Our teams are continuing to work on developing and testing updates for this issue, and our ongoing monitoring of the situation shows that attacks are still not widespread.

We don’t have any new estimates on release timelines. I can say that our ongoing testing so far has not raised any issues that would make us believe we might be looking at a longer timeline. However, testing is ongoing.

While we called this out in our security advisory and our initial and subsequent postings, we have still have gotten some questions from customers about whether this vulnerability exists in any non-server Windows operating systems. The answer to that is no: this vulnerability only affects Windows server operating systems, specifically those with DNS installed.

We know this because as part of our Software Security Incident Response Process (SSIRP) after we identify a vulnerability one of the first things we do is to establish the scope of affected software. We do this looking at the source code for the affected component in all publicly supported versions of the product. We look to see if the code that contains the vulnerability is present in the source code. In the case of this vulnerability, the code with the vulnerability is in the DNS server component. That component isn’t present in Windows client operating systems. Because of this, we can say that client systems are not at risk from this vulnerability.

As always, we’ll keep you updated with new information about our work and the situation as we have it.

Thanks.

Christopher

Hi everyone.  Jonathan from the SWI team here.  Christopher asked me to write a guest blog entry introducing and providing some background on a new KB article that we published a few minutes ago.

We have seen lots of activity in the security community about the registry key workaround we published in Security Advisory 935964.  As a reminder, the DNS service listens on RPC over TCP, RPC over named pipes, and LPC.  The workaround changes this behavior to listen on LPC only to block any possibility of remote attacks.  We know that this has an impact on remote administration requiring a terminal services or console logon to use any admin tools.  I assure you that we're working as fast as we can to get a well tested, comprehensive security update out to you all, which addresses the issue.  In the meantime, the workaround is good protection against the attacks we’ve seen so far.

As I was saying, there's a lot of chatter in the security community around this issue.  One of our friends, Jesper Johansson, had a great idea and posted a script to his blog that helps deploy the workaround to all domain controllers in an enterprise.  Our PSS team took his idea, added some error handling to it, and built it into a KB, which we hope will be useful to you, in protecting against this vulnerability and limiting your attack surface in general on those servers that do not require remote DNS service management.

You can find the KB at http://support.microsoft.com/kb/936263

We continue to monitor the situation and will update you with new information on this situation via the blog.

Thanks,

Jonathan

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

Hello everyone,

This is Christopher Budd. I wanted to let you know that we’ve made a revision to our security advisory to provide some additional details and clarifications.

First, though, I wanted to let you know that the situation has not changed. Our teams are continuing to work on developing and testing updates for this issue, and our ongoing monitoring of the situation shows that attacks are still not widespread.

Currently, we are aware of four pieces of malicious software attempting to exploit this vulnerability. However, none of these automatically self-propagate. We have technical details on each of these in our Malicious Software Encyclopedia:

·       Siveras.B

·       Siveras.C

·       Siveras.D

·       Siveras.E

Also, we have an entry with information on the public proof of concept code from this past weekend here:

·       Siveras.A

I’ll note once again that the workarounds in our security advisory are effective against the attacks we’ve seen so far.

We have added one new piece of information to our security advisory. Specifically, we’ve added port 139 to the list of ports you should block for the Firewall and IPSec workarounds.

The other updates we’ve made clarify some of the information already in the security advisory based on customer questions. Specifically we’ve clarified that:

·        All the workarounds are effective against attempts to exploit the vulnerability over RPC, port 445 and port 139.

·        For port 445 and 139, an attacker will need to authenticate using a valid username and password. These do not allow unauthenticated attacks the same way RPC does. However, the guest account, which is disabled by default, could be used if it has been enabled.

·        Customers may encounter issues with DNS Server local administration and configuration using DNS administration tools when the computer name is exactly 15 characters and not 15 characters or more as was first posted. Using the Fully Qualified Domain Name (FQDN) of the computer will avoid this issue.

Our work and monitoring of this issue is ongoing and as always, we’ll let you know when we have more information.

In the meantime, we continue to encourage customers to deploy the workarounds, preferably the registry key workaround, and to update their security products with the latest signatures to help ensure they have the latest protections.

Thanks.

Christopher

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

Hi Everyone,

This is Mark Miller. For those who may not know, I’ve been the Director of Security Response Communications since October of last year. I wanted to let you all know that we have implemented a new Windows Live Alert for postings to this blog. These alerts are delivered to your email inbox, SMS and/or instant messaging and will let you know that we’ve posted something here. Given the importance of these communications, we wanted to make sure to give you as many different ways of receiving them as possible. Just note that this automated service monitors the RSS feed of the blog and will generally alert you within 5 to 60 minutes of the blog posting. Times may vary however. You can click here to subscribe or click the Windows Live Alert graphic to the right.

I also want to mention the changes we just made to the look of the blog. We just thought it was time to make it look more like the important communications tool that it is.

As always, we appreciate continued customer feedback on all of our guidance and communications.

Mark

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

Hello,

This is Christopher Budd. I wanted to let you know about two updates we’ve made as part of our regular process to Knowledge Base article 925902. These discuss new known issues a small number of customers have encountered with MS07-017.

First, we’ve added BMC PATROL 7.1 (now called Performance Manager, by BMC Software, Inc) to the list of applications affected by the issue discussed in Knowledge Base article 935448. The hotfix that is available addresses the issues in this application.

Also, we’ve noted in the article that version 1.64 of the Realtek HD Audio Control Panel does not exhibit the issue discussed in the article. If you are encountering the issue discussed in Knowledge Base article 935448 you can install the newer version of the Realtek HD Audio Control Panel to resolve the issue.

Finally, we’ve posted a new Knowledge Base article 935843 that discusses a new issue for which there is a hotfix available. Specifically, after installing MS07-017 some customers have experienced an issue when printing from SQL Reporting Services to a Printer Command Language (PCL) printer.

Because these issues are very limited in scope, we don’t plan to release the new hotfix through Windows Update or Microsoft Update or change the detection logic for the existing hotfix. Customers affected by any of these newly identified issues can download and apply the available hotfix to resolve the issue.

As part of their regular testing and deployment, we continue to encourage customers to review the KB articles and apply the hotfixes as appropriate.

Thanks.

Christopher

Updated April 20, 2007: Subsequent to this original posting, AVG Anti-Virus Control Center from Grisoft, and BricoPack Vista Inspirat from CrystalXP were found to not be affected by the issues discussed in Knowledge Base article 935448. The Knowledge Base article has been updated and this posting corrected. Please see the "Similar problems and solutions” section of the Knowledge Base article for more information.

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

Hello everyone,

This is Christopher Budd. I wanted to give you the latest information from our monitoring of the new attack we mentioned yesterday. I also wanted to address questions we’ve gotten from customers about when we think we’ll have updates ready to address this issue.

We have been monitoring the situation overnight and working with our Microsoft Security Response Alliance (MSRA) partners and attacks are still not widespread.

As part of our Software Security Incident Response Process (SSIRP) we’ve taken some additional steps overnight to help protect customers. First, we have worked to help provide information to our MSRA partners so their products can provide additional protections to customers. We’ve updated our Windows Live Safety Scanner and Windows Live One Care with protections for customers. We have also been working with our partners in the Global Infrastructure Alliance for Internet Safety (GIAIS) program to take steps to help keep attacks from spreading.

While we don’t have a firm estimate on when we’ll complete our development and testing of updates for this issue, we have teams around the world working on it twenty-four hours a day, and hope to have updates no later than May 8, 2007 for the May monthly bulletin release. However, this is a developing situation and we are constantly evaluating the situation and the status of our development and testing of updates.

For this issue, our teams are working on developing and testing 133 separate updates: one in every language for every currently supported version of Windows servers.  Each of these has to be tested to ensure they effectively protect against the vulnerability. Because DNS is a critical part of the networking infrastructure, they also have to be tested to ensure that changes introduced by the updates don’t pose a greater risk than the security issue we’re addressing.

We again encourage customers to deploy the workarounds discussed in the security advisory. These are effective against the attacks we’ve seen so far. Additionally, we want to urge customers specifically to evaluate the registry key workaround and ensure they’re using the latest signatures for their security protection product.

We are continuing to monitor the situation closely. As we have been doing, we’ll make updates as we have new information through our security advisory and through the MSRC weblog.

Thanks.

Christopher

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

Hello everyone, this is Christopher Budd.

I wanted very quickly to update you with some new, important, information that we have on this situation.

Our ongoing monitoring in conjunction with our MSRA partners indicates that we are seeing a new attack that is attempting to exploit this vulnerability. At this time, the attack does not appear widespread.

As part of our Software Security Incident Response Process (SSIRP), we continue to work through a variety of channels to encourage customers to quickly deploy the workarounds provided in the Advisory.  By quickly deploying the workarounds customers can mitigate the risk of an effective attack on their networks.

Once again, we want to strongly advise customers to deploy the workarounds in their environment as soon as possible. In particular, we’re encourage customers to deploy the registry key workaround. Also, we strongly urge customers to deploy the latest signatures for their security products.

Our teams are continuing to work around the clock on a security update for this issue, but we are advising customers to deploy the workarounds immediately while we continue that work. And we’re constantly monitoring the situation along with our MSRA partners. As soon as we have any new information, we’ll update you through the advisory and the MSRC weblog.

Thanks.

Christopher

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

Hello everyone,

This is Christopher Budd. I wanted to give you a brief update with the latest information on the situation from our ongoing work over the weekend.

Our teams are continuing their work to develop a security update to address this issue. Our ongoing monitoring of attacks in conjunction with our MSRA partners indicates that attacks are still limited. We are aware though of public disclosure of proof of concept code to exploit the vulnerability. We continue to urge customers to deploy the workarounds in their environments as quickly as possible.

We have today made some new additions to the advisory. We’ve added some new information about the impact of some of the workarounds on systems with 15 character, or longer, system names. We’ve also noted that it is possible for a user with valid logon credentials to access the vulnerability over port 445.  As always, we’re continuing to work around the clock to monitor the situation closely, continue our technical investigations and develop a security update to address this issue.

We’ll continue to update the advisory with new information as well as the MSRC weblog.

Thanks.

Christopher

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