Recently we announced the Internet Explorer 8 XSS Filter and talked a bit about its design philosophy. This post will describe the filter’s architecture and implementation in more detail.

Design Goals

The Internet Explorer 8 XSS Filter is intended to mitigate reflected / “Type-1” XSS vulnerabilities in a way that does not “break the web.” Our baseline approach needs to satisfy the following three conditions:

• The XSS Filter must be compatible.
  • There should be minimal, ideally zero, disruption to benign content/data. We might be able to achieve effective filtering if we were to drop all non-alphanumeric characters from input, however this would be an unrealistic and overbearing solution. Any solution that involves directly modifying request URLs is likely to persist corrupted data on the server-side. Similarly, approaches that would ask the user questions they can’t answer or block entire pages are not acceptable.
• The XSS Filter must be secure.
  • In general it must not be possible to subvert the filter by modifying attacks that are otherwise intentionally blocked. Although the XSS Filter cannot mitigate all possible XSS attacks, it can win some critical battles decisively. We can push as far as possible to maximize the XSS Filter’s effectiveness as long as we are also careful not to compromise compatibility or performance.
• The XSS Filter must be performant.
  • Users prefer a fast browser to a slow one, even if the slower one is “more secure.” So some approaches are simply not acceptable for performance reasons. For example, creating an extra instance of the browser rendering engine for each navigation would be too impactful to consider.

In implementing the filter, we made decisions to best meet the above goals.

Practical Considerations

The XSS Filter must be in a position to observe and intercept requests and responses from the browser to the web server. In Internet Explorer, this is possible via a MIME Filter. The prototype implementation of the XSS Filter was in fact implemented as a MIME Filter, but for performance it was moved into MSHTML (the browser rendering engine) when we built Internet Explorer 8.

Architecture / Implementation

 
Figure A: XSS Filter Hosted in Internet Explorer 8

 
Figure B: XSS Filter Logic Flow

Figures A and B depict a high level view of the XSS Filter. Let’s dig into the details.

For performance, the XSS Filter only takes effect for navigations within the browser which can result in the execution of script. There’s no need for the XSS Filter to operate on resources such as images (as long as they are truly images when rendered by Internet Explorer).

The filter also checks the source and destination URLs of navigations within the browser. If the navigation is cross-site, or the source cannot be determined (ex: the user clicked on a Favorite) then the navigation is filtered.

The XSS Filter can be enabled/disabled per-zone. For the Beta 2 release the XSS Filter will be enabled for the Internet and Restricted Sites zones, but not the Local Intranet zone. Administrators can choose to enable or disable the XSS Filter for any zone via group policy.

The core XSS Filter engine operates in two stages:

1. HTTP GET / POST data is scanned to match a set of heuristics that identify XSS attack vectors. Matches are used to build signatures to identify markup/script as replayed in the HTTP response.

2. Generated signatures are used to scan the HTTP response. Markup/script which has been identified by a signature is neutered to block execution.

Validating that an XSS attack has actually been replayed into the response maximizes XSS detection reliability – “reflected XSS” requires reflection. Having the capability to identify and neuter the replayed markup/script allows the filter to avoid overbearing mitigations such as querying the user, modifying outgoing requests, or blocking entire pages.

Our approach is performant in that the only notable “heavy lifting” is the scan of the HTTP response body, which will only occur in cases where signatures are generated. Signature generation is highly indicative of an actual XSS attack and it is rare during everyday browsing.

Fun with Regular Expressions – Part 1: Heuristics

If a navigation has met the criteria for filtering, the filter takes the URL as well as any POST data associated with the request, decodes it as necessary, and uses regular expressions to identify XSS attack vectors. These case-insensitive patterns are the filtering heuristics. Here is an example:

{<sc{r}ipt.*src[whitespace or forward-slash]*=}

This heuristic will identify SCRIPT tags with SRC attributes. While SCRIPT tags may be common in HTML, their presence in a URL or POST data is one indication of an XSS attack.

In the example heuristic above, note that the character within the inner braces is what we will refer to here as the neuter character. Each heuristic can have one or more neuter characters. Each neuter character, in this case ‘r’, indicates a character that will eventually be modified by the filter in the HTTP response body in order to block the XSS attack. The ‘#’ character is used as the neuter replacement character – it is effective in breaking HTML elements as well as script blocks into which it is injected.

The selection of neuter characters in any heuristic is very important. The wrong neuter characters chosen for a heuristic can subvert the filter. As an example, picking a quote symbol as a neuter character would cause the filter to neuter quotes. A smart attacker could use this behavior to force a match and neuter a quote on a page, intending to enable an XSS attack that wouldn’t otherwise be possible.

A match on a heuristic does not in and of itself trigger the filter to detect XSS. Rather, it indicates to the filter that the HTTP response body must be examined to validate that the script in the input URL or POST data was in fact replayed to the output page.

The decoding process briefly mentioned above is flexible and can also account for artifacts of various web platforms. As necessary, the filter generates additional signatures (see below) based on alternate interpretations of the same input data. So for example, because malformed URLEncoded characters may be handled differently for different web platforms, the filter must be capable of building proper signatures regardless.

Fun with Regular Expressions – Part 2: Signatures

As heuristics are matched, the filter generates one signature for each match. A signature is a new regular expression that will be used to scan the HTTP response body for the replayed suspect input. The neuter replacement character is temporarily put into place in the input after a signature is matched. Matching then continues for a heuristic until no more matches can be found in the input. Signatures are generated for URLs without neuter replacement characters in place. Otherwise the signatures would themselves contain neuter replacement characters and they would not correctly match attacks present in the HTTP response.

With each heuristic, a list of safe characters is provided. For the heuristic that detects script tags, the safe characters are the greater-than and less-than characters and also alpha-numerics. The safe characters effectively form the essence of the XSS attack the filter is attempting to identify.

Safe characters are restricted to the “low-ASCII” range (0x00 – 0x7F) so that we can essentially remain character-set agnostic. Character sets that are capable of alternate “low-ASCII” encodings (eg: UTF-7) are not currently special-cased, however some new restrictions are being placed on the general usage of these character sets moving forward. (These changes are outside the scope of this blog post but stay tuned to my blog for more details).

Here is an example match for the heuristic that detects script tags:

<SCRIPT src=”http://www.fabrikam.com/evil.js”

The signature generated for this match would be:

<SC{R}IPT¤src¤¤http¤¤¤www¤fabrikam¤com¤evil¤js¤

Each ¤ in the signature indicates a non-safe character from the original match. A sequence of zero to N unspecified characters will match any ¤. (Currently N is 10)

If no signatures have been generated for a particular page then the filter permits the page to load without modification – no XSS was detected.

However, if signatures do exist, the filter scans the HTTP response body for each signature. Once identified, the filter records exactly which character(s) must be neutered, as indicated in the signature by the characters within the braces. Once the signature list is fully processed the neuter replacement characters are put into place and the HTTP response body is passed on to render in the browser.

The page will render normally except the information bar will notify the user that the page was modified and the XSS attack will be disabled.

XSS Filter Limitations

Like all security mitigation and protection technologies, the XSS Filter’s approach does have limitations, being that it is a pragmatic balance between application compatibility, security, and performance. Some examples:

• Injection into some contexts is not blocked. Ex: Scenarios where content can be injected directly into javascript without breaking out of a string.

• Injections facilitated by some HTTP headers are not currently blocked. Ex: “Referer” based injection.

• If a page contains multiple nearby injection points, attacks can be constructed that thwart the XSS Filter.

These are all issues that undoubtedly occur on real web sites. The XSS Filter design philosophy dictates that we make a distinction between issues that generally enable the XSS Filter to be bypassed vs. issues that apply only in certain situations. The issues above, while very notable, clearly fall into the latter category. As time goes on we will continue to enhance the XSS Filter to maximize its effectiveness, however we will not compromise web site compatibility in the process.

Conclusion

It is challenging to mitigate XSS in a way that balances the needs of compatibility, security, and performance. The XSS Filter’s two-stage approach helps us achieve these goals by very specifically targeting reflected (“Type-1”) XSS attacks. This architecture allows us to mitigate the XSS most commonly found across the web today, by default, for users of Internet Explorer 8.

- David Ross, SVRD Blogger

*Postings are provided "AS IS" with no warranties, and confers no rights.*

August 19, 2008, 4:15pm: Updated with correct date

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.

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

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

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

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

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.

In early January you may have read posts on security distribution lists regarding two ActiveX Controls released by Microsoft. We have investigated those controls and fortunately, they are not exploitable since IE does not treat them as being safe.  We wanted to give you some background on how to evaluate whether a potential vulnerability found in an ActiveX control is an exploitable condition in Internet Explorer.

Each time IE finds an embedded ActiveX control in an HTML web page, IE will perform the following checks to verify if it is safe for initialization and scripting:

• IE will determine if this ActiveX Control is kill-bitted or not. If it is, IE will not load the control.
• IE will determine if this ActiveX Control implements IObjectSafety.
• If it does, IE will query through this interface for “Safe for Initialization with data” and “Safe For Scripting”.
• If it does not implement IObjectSafety, IE will look for these properties in the registry under the following implemented categories: {7DD95802-9882-11CF-9FA9-00AA006C42C4} (Safe for Initialization) and {7DD95801-9882-11CF-9FA9-00AA006C42C4}(Safe For Scripting).

Once IE knows these two properties it will follow this logic (under the default configuration):

• IE will load the control to query its IObjectSafety interface.
• If the control does not implement IObjectSafety and does not have the Safe For Initialization or Safe For Scripting properties in the registry, IE will unload this ActiveX Control.
• If the control is Safe for Initialization, IE will instantiate it and IE can receive data through param attributes and the DATA attribute of the object html tag.
• If the control is not Safe for Scripting, IE will not script this control through JavaScript or any other scripting language.
• If this control is Safe for Scripting, IE will allow scripting of this control.

If a malicious web page tries to take advantage of any of these controls and its methods, IE will NOT script them due to the classid’s properties (“Safe for Initialization” and “Safe for Scripting”). The attacked user will see IE’s gold bar since IE treats them as unsafe, and scripting them is a requirement for the successful exploitation of these controls.

In general, IE (in the Internet Zone) will not script and/or load this type of classid as mentioned in this article: “INFO: How Internet Explorer Determines If ActiveX Controls Are Safe” http://support.microsoft.com/kb/q216434/

Analysis about the recent posts can be found below:

• http://www.milw0rm.com/exploits/4873 : The classid {008B6010-1F3D-11D1-B0C8-00A0C9055D74} has the following properties:

Clsid: {008B6010-1F3D-11D1-B0C8-00A0C9055D74}
Progid: VisualFoxpro.Application.6
Binary Path: C:\Program Files\Microsoft Visual Studio\Vfp98\vfp6.exe
Implements IObjectSafety: False
Safe For Initialization: False
Safe For Scripting: False
KillBitted: False

With the installation of Visual Fox Pro 6 this classid will automatically be available in the system. Since it does not implement IObjectSafety, IE will determine whether the file is safe to use via some properties on the registry for this control such as “Safe for Initialization” and “Safe for Scripting”, in this case “false”.

• · http://www.milw0rm.com/exploits/4874 : The classid {B617B991-A767-4F05-99BA-AC6FCABB102E} has the following properties:

Clsid: {B617B991-A767-4F05-99BA-AC6FCABB102E}
Binary Path: C:\Windows\System32\RICHTX32.OCX
Implements IObjectSafety: True
Safe For Initialization (IObjectSafety): True
Safe For Scripting (IObjectSafety): False
Safe For Initialization (Registry): False
Safe For Scripting (Registry): False
KillBitted: False

Even though this control implements IObjectSafety, IE will not trust it since it is not marked as “Safe for Scripting”. “Safe for Scripting” is required in order to trigger the vulnerability: writing files via SaveFile() method. Since IE will not script it, there is no vulnerability through IE in its default secure configuration.

We have attached source code to this blog post to list the various properties of ActiveX controls. This tool was used to generate the output above dumping the ActiveX properties of the milw0rm posts.

- Security Vulnerability Research & Defense Bloggers

*Postings are provided "AS IS" with no warranties, and confers no rights.*

7/29/09 Update: Fixed a typo in the Safe for Scripting CLSID. Thanks to Leo Davidson for bringing this to our attention.