Part 3 of our MS08-001 blog post series mentioned that Windows Server 2003 does not expose an attack vector to the vulnerable IGMP code execution vulnerability by default.  Windows XP and Vista enable UPnP (Universal Plug-and-Play) which exposes an attack vector to the vulnerable code but Windows Server 2003 does not enable UPnP.  As a result, the WS03 machine will ignore IGMP messages received from the network.

We have received a few questions about Windows Server 2003's exposure to the IGMP vulnerability.

Question 1: By default, Win2k3 server joins to multicast group 224.0.0.1. Does it mean that Win2K3 is vulnerable by default? And the rating in MSRC bulletin is wrong?

Answer:  The bulletin rating is correct. Win2k3 server is not vulnerable to IGMP issue when it only joins to 224.0.0.1.

Observe the netsh command output on a default configuration of Win2K3 server:

>netsh int ip show joins

Interface Addr   Multicast Group

---------------  ---------------

10.1.1.1         224.0.0.1

224.0.0.1 is all hosts on the subnet. The reason that win2k3 server is not vulnerable despite being joined to  224.0.0.1 is because Windows ignores IGMP queries to that address.  Here's the actual code:

    } else {
      // If all-hosts address, ignore it
      if (IP_ADDR_EQUAL(IQH->igh_addr, ALL_HOST_MCAST)) {
          DEBUGMSG(DBG_WARN && DBG_IGMP,
                    (DTEXT("Dropping IGMPv3 query for the All-Hosts group\n")));
          return;
      }

Question 2: How can I tell whether my Windows Server 2003 machine is vulnerable?

Answer: If the server joins to any multicast group other than 224.0.0.1, then it is vulnerable to IGMP attack.

Using the following netsh command will show the multicast groups to which the machine is joined.

netsh int ip show joins

For example, if the WINS component is enabled in Win2k3 server, the output of the netsh command above would be:

Interface Addr   Multicast Group

---------------  ---------------

10.1.1.1         224.0.0.1
10.1.1.1         224.0.1.24

224.0.1.24 is IP multicast group for WINS. The configuration above (if unpatched) is vulnerable to the IGMP attack.

Question 3: Even if a server is not joined to a multicast group other than 224.0.0.1, could it still be affected if an attacker sent a *unicast* IGMP packet?

Answer: No. Though the host would receive the unicast IGMP packet, valid multicast address needs to be contained in IGMP query payload so the packet would be ignored.

Security bulletin MS08-001 addresses vulnerabilities described by two separate CVE numbers, as you can see in the bulletin. This post provides an overview of the two issues, the affected platforms and notes on the severity. We’ll be following this post up with two further entries that look at each issue in more detail.

CVE-2007-0066 describes a vulnerability in parsing ICMP router advertisement packets. These packets are not processed by default on any supported version of Windows. If a computer is configured to process router discovery protocol packets and encounters this type of malformed packet, the Windows kernel will bugcheck (blue screen of death) and reboot. A separate blog post goes into more detail about the registry keys governing this behavior on each supported platform.

CVE-2007-0069, the more serious of the two vulnerabilities, involves the way the TCP/IP stack handles IGMP protocol packets. Mark researched the exploitability of this issue and you'll find his research and more detail about the vulnerability in the next blog post.

For those of you readers who are more visual, here's a picture describing the exposure of the vulnerabilities addressed in the security bulletin, by CVE:

Severity rating in detail

Looking at the severity ratings for the various versions of Windows, you'll notice they range from Moderate (Windows 2000) up to Critical (Windows XP and Vista). While the bulletin covers the reasons for the severities well, I'm sure some confusion will still arise.

I'll try to anticipate your questions and answer them here:

• Why is Windows 2000 rated as Moderate while other platforms are Critical or Important?
  Windows 2000 is not vulnerable to the IGMP attack, so the code execution risk from this attack does not apply. Windows 2000 is only vulnerable to the denial-of-service attack involving ICMP messages.
• Why is Server 2003 rated as Important?
  Server versions of Windows such as Windows Server 2003 are not vulnerable to the IGMP code execution vulnerability. WS03 does not enable UPnP (Universal Plug and Play) by default, and no other services use multicast. As a result, the WS03 machine will ignore IGMP messages received from the network. UPnP is a network service that relies on IP multicast, and is only enabled by default on Windows XP and Windows Vista.
• When might Server 2003 be vulnerable?
  Windows Server 2003 would only be vulnerable if an application or service on the machine is using IP multicast, for example if UPnP is manually enabled or a 3rd-party multicast application/service is being used.
• Why does Vista have more affected protocols than XP/Server 2003?
  Vista, being the most recent version of Windows, has the most current protocol support. It includes support for IPv6 by default, including the MLDv2 protocol (Multicast Listener Discovery v 2). This protocol is the IPv6 equivalent of IGMPv3 for IPv4. MLDv2 is not supported prior to Vista, so earlier operating systems are not vulnerable to the MLDv2-specific attack.

The next post looks at the ICMP vulnerability in some more details and covers important mitigations.

Update: The graphic and text were updated to reflect accurate CVE ID numbers.

 - Security Vulnerability Research & Defense bloggers

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

This is the second post in the three-part series covering MS08-001. In this post we’ll look at the ICMP vulnerability (CVE-2007-0066) in more detail. This vulnerability is caused by Windows TCP/IP’s handling of the ICMP protocol, specifically regarding router advertisement messages. This post covers the mitigating factors for this vulnerability in more detail.

Technical description of the vulnerability

Internet Control Message Protocol (ICMP) router discovery is the use of ICMP messages to discover the default gateway on a network segment when a default gateway is not manually configured or assigned by using DHCP. ICMP router discovery consists of two ICMP messages: the router solicitation and the router advertisement. A router solicitation is sent by a host to discover the routers on the network. A router advertisement is sent by a router in response to a router solicitation and periodically to notify hosts on the network that the router is still available.

Windows TCP/IP incorrectly handles fragmented ICMP router advertisement messages. (When a message is too large to be sent in one chunk, IP allows it to be fragmented into several pieces and the receiving machine is then responsible for re-assembling the original message.) Fragmented router advertisement messages can cause the system to read invalid memory, leading to a system crash. (The crash will happen sporadically depending on the contents of memory when the ICMP message is received). Since at worst the targeted machine will crash, and no code execution is possible, this issue results in a denial-of-service (DoS).

Mitigation

The mitigation factor of this vulnerability is that it can only be reached if Router Discovery Processing is enabled. There are some differences between Win2k and Win2k3/WinXP about the default setting for the Router Discovery Processing.

Important: Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base: 256986 (http://support.microsoft.com/kb/256986/) Description of the Microsoft Windows registry

The setting is controlled by the registry key PerformRouterDiscovery under: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ interface_name

For Win2K, there are 2 values for PerformRouterDiscovery:

• 0 (disabled)
• 1 (enabled)

0 is the default setting if the key is not present. Therefore, ICMP router discovery is disabled on Win2k by default.

For Win2k3 and WinXP, a new value is added for PerformRouterDiscovery key:

• 2 (enable only if DHCP sends the Perform Router Discovery option)

The default setting if the registry key is not present is 2, meaning ICMP router discovery is disabled by default on TCP/IP for host computers running Windows XP or Windows Server 2003 operating systems, unless the host receives the perform router discovery option from a DHCP server.

You can also configure a server running Windows Server 2003 and the Routing and Remote Access service to support ICMP router discovery as a router. http://technet2.microsoft.com/windowsserver/en/library/a70f1bb7-d2d4-49f0-96d6-4b7414ecfaae1033.mspx?mfr=true contains more details about which DHCP option controls this setting.

Based on the above info, you can decide whether your system is affected by this vulnerability.

Next up, we’ll look into the IGMP vulnerability in more detail and see why, although we’ve rated it Critical on most platforms, we think successful exploitation for remote code execution is not likely in practice.

Update:  Text updated with correct CVE number.

- Security Vulnerability Research & Defense bloggers

This is the final post in the three-part series covering MS08-001. In this post we’ll look at the IGMP vulnerability (CVE-2007-0069) and why we think successful exploitation for remote code execution is not likely.

This vulnerability is around Windows’ handling of the IGMP and MLD protocols. These two protocols are used to control multicast traffic over IPv4 and IPv6 networks, enabling hosts to advertise their intention to send & receive multicast traffic. This allows routers to maintain the necessary state so that they can forward data to the network segments. IGMP is the protocol used for IPv4, and MLD is used for IPv6 multicast.

Source-specific multicast (SSM) is a recent addition to IP multicast and allows a host to receive multicast traffic from only specific sources. IGMPv3 and MLDv2 are the versions of the protocols that support SSM.

A vulnerability in the tcpip.sys driver in Windows exists due to the way the TCP/IP stack handles network packets specifying SSM data. This bug can be exploited to gain remote code execution (RCE) in the context of the kernel (SYSTEM). This attack can be performed by remote, anonymous attackers.

The first question you are probably asking is "How likely is exploitation of this issue?"

Even though this bulletin is rated Critical for XP and Vista (the bulletin describes mitigating factors that lower the severity on Windows Server 2003) there are a number of factors that make exploitation of this issue difficult and unlikely in real-world conditions:

• An attack is likely to cause high CPU usage by the target, unless packets are sent slowly.  Due to the way the TCP/IP code processes incoming SSM messages, the machine will consume large amounts of CPU when it is under attack. This can be controlled to some extent by the attacker by sending fewer packets per second. An attacker trying to send packets blindly at full speed will cause the target to use 100% CPU and become unresponsive. This has the effect of causing the TCP/IP code to drop messages, which makes it harder for the attacker to control the attack and make exploitation reliable.
• The attack is timing-sensitive, due to the nature of the IGMP protocol and the high CPU usage that is likely on the target machine.
  The IGMP protocol requires the use of a timer which is used to trigger a multicast report (which triggers the vulnerable code). The timer is created when the initial IGMPv3 or MLDv2 query message is received. The TCP/IP stack chooses a random value between (0,MaxResponseTime), where MaxResponseTime is the value in the received query (attacker controlled). Each new IGMPv3/MLDv2 query that is received can have a different MaxResponseTime value in it.  The existing timer is updated by selecting a random number between (0,MaxResponseTime), but only if the new value is smaller than the current value. This means that the attacker can:
• Specify the upper-limit of the timer value
• Trigger an immediate timer expiration at will. This is useful when launching an attack since the attack packets can use a large MaxResponseTime value, except for the last packet which uses a small value. This will then trigger the timer soon after the last packet is received.

However, since the timer value is chosen randomly, the attacker does not know when the timer will expire. Let’s assume the attack requires 300 packets worth of data. The attacker can send their packets, but the timer may expire mid-way through the transmission. When the timer fires, the list is emptied (and no overflow happens). The 2nd half of the attack continues and fills the list again, but there is no longer enough data to successfully attack the vulnerability.

The attacker can run their attack non-stop, and eventually they will be lucky enough to have the timer fire with the appropriate conditions to trigger the vulnerability. However, they don’t know for sure how many packets to send, or what will be in the buffer when they trigger the vulnerability.

To illustrate this in effect, this is a dump from a kernel debugger, showing the timer values as the attack is running:

unsigned long 0xd02    <-     Initial timer value chosen randomly

unsigned long 0x4b6    <-     Timer value reduced to a new random value

unsigned long 0x467

unsigned long 0x2ea

unsigned long 0x6b

unsigned long 0x28

unsigned long 0x16

Timed out!              <-     The timer expires and the buffer is emptied

unsigned long 0x1806    <-     Attack continues, a new timer value is chosen randomly

unsigned long 0xa71     <-     Timer value reduced to a new random value

unsigned long 0x291

unsigned long 0x15c

unsigned long 0xab

unsigned long 0x9b

unsigned long 0x27

Timed out!              <-     The timer expires and the buffer is emptied

• The state of the target machine is unpredictable since the target may have dropped some of the attacker's IGMP packets (e.g. if they are sent too fast), and the timing sensitivity may have flushed some data from the target's memory before the issue was triggered.
• The target machine will only store data in the attacker's packets that is unique (unique IP addresses), so the attacker cannot repeat the same value across large sections of the target machine's memory. Any exploit code would also need to be encoded to appear as unique IP addresses.
• The issue causes pool corruption which is similar to heap buffer overruns in user-mode code. These are typically harder to exploit reliably. Unsuccessful exploitation attempts will result in a bugcheck (a.k.a. "blue screen" or BSOD).

This concludes the end of our three-part series as it relates to MS08-001. 

At the end, we probably should note that you might be wondering if we are releasing too much technical detail about this vulnerability, which somehow could help miscreants develop an attack. Please be assured that these details cannot be used to create an attack and that the security of customers is our primary concern.

Update:  Updated with correct CVE number.

- Security Vulnerability Research & Defense

We have received a few inquiries about the full disclosure posting http://seclists.org/fulldisclosure/2007/Dec/0470.html , where a range check was added in Windows XP SP3 for the Terminal Server RPC function RpcWinStationEnumerateProcesses.  The speculation stated that this change was to hide an overflow condition, potentially leading to an exploitable vulnerability in previous Windows versions.  In reality, this update to the Terminal Service RPC interface definition was made to better adhere to our own RPC best practices.

From IDL Techniques for Better Interface and Method Design:

• For parameters marked with the [out, size_is] attribute tuple, and where the data length is known on the client side or where the client has a reasonable upper bound, the method definition should be similar to the following in terms of parameter attribution and sequence:

outKnownSize
(
[in,range(MIN_COUNT, MAX_COUNT)] long lSize,
[out,size_is(lSize)] UserDataType * pArr
);

In this case, the client provides a fixed size buffer for pArr, allowing the server-side RPC service to allocate a reasonably-sized buffer with a good degree of assurance. Note that in the example the data is received from the server ([out]). The definition is similar for data passed to the server ([in]).

Looking at the IDA disassembly, one can see that this value is used to retrieve a memory block from RtlAllocateHeap.  This memory is then passed into NtQuerySystemInformation which populates it with, you guessed it, various system information.  If an overflow existed due to this value, it would exist and be fixed in these lower level functions, not in a high level interface definition.

- Security Vulnerability Research & Defense bloggers

MS07-063 addresses a weakness in the SMBv2 message signing algorithm. SMB signing is a feature enabled by default on domain controllers to prevent man-in-the-middle attacks. As you can imagine, if an attacker on your local subnet can tamper with the SMB network traffic between your domain controller and domain-joined clients, they can cause all kind of mayhem. Windows 2000 and 2003 domain controllers use SMBv1 which uses a secure signing algorithm. When Vista and Windows Server 2008 communicate, they attempt to use SMBv2. SMBv2 message signing was originally implemented insecurely and then fixed with this security update.

Unless you use SMB message signing with SMBv2, this one probably won't affect you today but please do apply the update in preparation for any move to either Windows Server 2008 or client-to-client SMB signing with Vista clients. Vista SP1 and Windows Server 2008 Release Candidate 1 (and, obviously, the final released version) will have the fix. MS07-063 changes Vista RTM ("Released to Manufacturing"... no service pack installed) to use the same secure algorithm that internal builds of Vista SP1 and WS2008 RC1 already use.

You can spot any SMBv2 conversations on your network between unpatched Vista machines by just listening on the wire. MS07-063 changed the SMBv2 version number from 2.001 to 2.002. Kevin from our SWI Defense team documented this as part of our security investigation so I wanted to paste in a couple captures that he made to show the pre-patch and post-patch version numbers on the wire. If you're sniffing on your network and see SMB 2.001, that is an unpatched Vista machine. And actually both ends of that conversation would have to be unpatched because patched Vista, Vista SP1, or WS08 RC1 will choose to downgrade to SMBv1 rather than talk SMBv2 v2.001.

Here is a Negotiate Protocol Request with Vista pre-patch:

And here is what that looks like post-patch:

And again remember that this vulnerability is only relevant for signed traffic. Kevin also built a network capture to show the signature field. If it is full of NULLs then the packet is not signed. If it contains data, the packet is signed. Here is an example signed packet.

Update:  Blog reader Blake emailed us suggesting that we attach a full network capture showing signed SMBv2 traffic.  Kevin from the SWI Defense team had a capture of SMB2 (version 2.001 - pre-patch) already prepared so we are attaching it here.  You might notice that the capture includes some information about his test setup (machine name = "VM-Vista-RTM", login name = "Kevin").  We decided that data does not have privacy concerns so we didn't remove it from the capture.

Update:  Blog reader Ronnie correctly pointed out that the screenshots above were taken from Wireshark, not NetMon.  Sorry about that.

MS07-065 fixed a vulnerability in the Message Queueing service. On Windows 2000, a remote anonymous attacker could use this vulnerability to run code as local system on unpatched machines. Windows XP added defense-in-depth hardening to disallow remote access for this service that does not need to be exposed remotely. So on Windows XP, the attacker must be logged on locally on the box.

You'll see in the mitigations section of the bulletin that the MSMQ service is not started by default. Most installations of Windows do not require message queueing so the default install having it off by default reduces attack surface.

There is actually another mitigating factor present here that we didn't include in the bulletin because we could not authoritatively say that it was true in every case. The vulnerable code path only executes if your machine has a primary DNS suffix. Most of the time, only domain-joined machines have a primary DNS suffix. So it would have been great to say in the bulletin: "Machines not joined to a domain are safe" but that is not 100% accurate so we did not include that. Technically, an administrator could manually set a primary DNS suffix on a non-domain-joined machine.

You can check to see if your machine has a primary DNS suffix by running "ipconfig /all" and looking for the line that says "Primary Dns Suffix". If it is blank, your computer configuration is not vulnerable to this issue. If you do have a primary DNS suffix set, we would not recommend removing it blindly because that could affect many applications and the ability for your machine to access network resources.

We periodically identify workarounds or mitigations like this that we can't use for official guidance because they're either too nuanced or have some exception cases. When we discover something potentially useful but are uncomfortable listing it in the bulletin, we'll do our best to describe it here in this blog.

We are excited to have this outlet to share more in-depth technical information about vulnerabilities serviced by MSRC security updates and ways you can protect your organization from security vulnerabilities. You can read much more about the goals of the blog and about the SWI teams contributing to the blog in our “About” link: http://blogs.technet.com/swi/about.aspx 

The two posts below are examples of the type of information we’ll be posting.  We expect to post every “patch Tuesday” with technical information about the vulnerabilities being fixed.  During our vulnerability research, we discover a lot of interesting technical information.  We’re going to share as much of that information as possible here because we believe that helping you understand vulnerabilities, workarounds, and mitigations will help you more effectively secure your organization.