Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

January, 2008

  • MS08-001 - The case of the missing Windows Server 2003 attack vector

    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 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

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

    >netsh int ip show joins

    Interface Addr   Multicast Group

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

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

    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, 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

    ---------------  --------------- 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, 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.

  • MS08-001 - The case of the Moderate, Important, and Critical network vulnerabilities

    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.*

  • MS08-001 (part 2) – The case of the Moderate ICMP mitigations

    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).


    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 ( 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. 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

  • MS08-001 (part 3) – The case of the IGMP network critical

    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

  • XP SP3 range check hiding an overflow condition?

    We have received a few inquiries about the full disclosure posting , 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:

    [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