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