Because this is my first time writing this column, an introduction is in order. I am Bill Sisk, the response communication manager at the Microsoft Security Response Center (MSRC). I have been in the security space for some time now and really took the dive into security back during the Code Red days. I must have personally worked with at least 100 customers, helping to get them back on their feet… My family didn't see me for quite...
a few days.
The December 2007 bulletin release contains six security bulletins affecting Microsoft Windows and one affecting Internet Explorer. Three bulletins are rated Critical and four are rated Important.
In this month's column, I will focus on two of the seven security bulletins: MS07-063 which addresses a vulnerability in Server Message Block Version 2 (SMBv2) and MS07-065, which addresses a vulnerability in Microsoft Message Queuing (MSMQ). For your risk assessment and deployment planning, I will help you better understand the nature of these vulnerabilities and what systems should be updated.
MS07-063 addresses an Important vulnerability in Windows Vista SMBv2 that makes it possible for an attacker to execute malicious code in the context of the logged on user. If the user has administrative rights, the attacker can perform any action on the system. In contrast, a user with restricted rights reduces the actions that an attacker could perform. This security update revises SMBv2 to resolve the issue.
There are a couple of reasons that the rating of Important is appropriate for this vulnerability.
First of all, there are mitigating factors to combat the SMBv2 vulnerability. SMBv2 was introduced with Windows Vista. Earlier systems, such as Window XP and Windows 2003, were shipped with an older version of SMB; which, for the sake of clarity, I will refer to as SMBv1. When a Windows Vista system attempts to communicate with another system, the Vista system will attempt to negotiate a connection using SMBv1. However, in this negotiation process, the Vista system also includes information that is able to communicate with SMBv2 systems. If the system it is being connected to only supports SMBv1, then the two hosts will communicate using SMBv1. However, if the host supports SMBv2, then the two hosts will communicate using this version. Only Windows 2008 Server supports SMBv2. Consequently, only communications between Vista to Vista and Vista to Windows 2008 are susceptible to this vulnerability. Earlier versions of Windows , such as Windows XP and Windows 2003, are not vulnerable because the vulnerable code does not exist in SMBv1 included with these systems.
Secondly, if SMBv2 is not being used in your environment, SMBv2 can be disabled on Windows Vista systems via the registry. Information on how to disable SMBv2 can be found in the security bulletin.
As a side note, disabling SMBv2 can be a stop-gap measure if the security update will not be immediately applied.
MS07-065 addresses an Important vulnerability in MSMQ, which allows remote code execution. MSMQ may not be utilized in your environment because it is not installed by default and administrative credentials are needed to install it. However, it can be utilized by various types of applications in a computing environment including custom-developed Win32 applications, third-party applications and custom-web applications. I would like to focus on web applications to help you identify where MSMQ may be running in your environment. The following scenario could apply to Win32 custom and third-party applications as well.
Some web application architectures are comprised of a frontend website, an intervening server running MSMQ and a backend database. Data is entered via the website, then passed to the MSMQ server, which forwards the data to the backend database. This is sometimes done to ensure data integrity. Additionally, the website, MSMQ and the database may all be housed on one server.
With this in mind, it is important to work with internal data owners to pinpoint where MSMQ may be running so that you can plan security update deployment accordingly.
As you may already know, testing the security update on non-production machines first will save you a lot of headaches later. All of our security updates are rigorously tested before public release, but we cannot duplicate the multitude of diverse computing environments.
If you haven't already, I would encourage you to become familiar with the next version of the Microsoft Baseline Security Analyzer (MBSA), slated for release soon, which will have full Microsoft Vista support as well as other enhancements.
I want to encourage you to take a moment and register for our regular monthly security bulletin webcast. For December 2007, it will be held on Wednesday, December 12 at 11 a.m. Pacific Standard Time.
Adrian Stone, lead security program manager, and I will review information about each bulletin to help you with your planning and deployment. Most importantly, after our review session, we will answer your questions live -- with information from our assembled panel of experts. If you can't make the live webcast, you can also access it on-demand.
Please take a moment and mark your calendars for the January 2008 monthly bulletin release. The release is scheduled for Tuesday, January 8, 2008 and the advance notification is scheduled for Thursday, January 3, 2008. Look for the January edition of this column on release day with information to help you with your planning and deployment of the January 2008 security bulletins.