Security Research & Defense

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

Security Research & Defense

  • Welcome to the new Microsoft Security Vulnerability Research and Defense 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.

     

    Please email us with any questions or comments at switech@microsoft.com
  • MS07-065 - The case of the significant suffix

    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.

  • MS07-063 - The case of the insecure signature

    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:

    SMBv2 version 2.001

    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.

  • XP SP3 range check hiding an overflow condition?

    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.

    image

    - 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

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

    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

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

    ms08-001-exposure

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

  • Not safe = not dangerous? How to tell if ActiveX vulnerabilities are exploitable in Internet Explorer

    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.

    image

    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:

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

    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.

  • The Kill-Bit FAQ: Part 1 of 3

    It is very common for Microsoft security bulletins to include “Kill-Bits” to disable individual ActiveX controls / COM objects. Here is the first part of a three-part FAQ we have developed to answer some questions around the Kill-Bit and related functionality.

    The Kill-Bit FAQ – Part 1 of 3

    What is the Kill-Bit?

    The Kill-Bit (a.k.a. “killbit”) is not actually a bit. The Kill-Bit is a registry entry for a particular CLSID that marks the COM object / ActiveX control referenced by that CLSID as non-loadable in the browser and other scriptable environments. Microsoft releases Kill-Bits in security updates to block vulnerable ActiveX controls and COM objects which are vulnerable to security flaws when hosted in the browser.

    Issuing a Kill-Bit for the control marks that particular control as forbidden to instantiate in the browser. Issue a Kill-Bit by setting the Compatibility Flags value to 0x400 for a control in the registry as described in KB Article 240797.

    Where are Kill-Bits in the registry?

    Kill-bits are located in the registry:
    x86 IE / x86 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control

    x64 IE / x64 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control

    x86 IE / x64 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control

    (3/11/2009 Update: added detail on x86 / x64 scenarios)

    clip_image002

    Warning - Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Modify the registry at your own risk.

    Note that not all CLSIDs listed in this location are killed, only controls containing 0x400 in the Compatibility Flags DWORD value. The acceptable values for Compatibility Flags are documented here.
    If you are setting a Kill-Bit, you may want to ensure that you don’t wipe out any existing Compatibility Flags set for the CLSID being killed. If you are removing a CLSID, to preserve any pre-existing Compatibility Flags, subtract 0x400 from the Compatibility Flags DWORD value and only remove the CLSID key if the Compatibility Flags value was set to 0x400 exactly.

    What applications respect the Kill-Bit?

    The Kill-Bit is respected in Internet Explorer (all zones) and also in Microsoft Office scenarios where objects are embedded within documents. The Kill-Bit should also be effective by default in any other application or platform that hosts the IE browser’s rendering engine (MSHTML). A notable exception are HTAs – with an HTA it is already possible to load unsafe controls and run arbitrary code. HTAs are an unsafe file type.

    (3/11/2009 Update: HTAs do currently respect the Kill-Bit for objects instantiated via the OBJECT tag.  The Kill-Bit is not respected when HTAs instantiate objects in script.  Thanks to Nicolas Noakes for reporting this. The Kill-Bit behavior within HTAs may change in the future to become more consistent.)

    A control could conceivably have a flaw so severe that a Kill-Bit does not effectively block all attack vectors. For example, imagine a control that is found to implement a web server which suffers from a buffer overrun in the code responsible for parsing web requests. In this case, a code fix must be issued – simply implementing a Kill-Bit will not provide a comprehensive solution because any application which uses the control is exposed to the vulnerability.

    If an application or platform hosts controls and allows those controls to effectively be driven by untrusted data, that environment should respect Safe for Scripting, Safe for Initialization and Kill-Bit logic. Otherwise, the environment should provide some other equivalently or more restrictive policy, such as an allow-list of known-good scriptable objects.

    Why does my vulnerable control / object need a Kill-Bit?

    Kill-Bits must be issued to prevent old / vulnerable signed versions of controls from being effectively foisted on users. Even if a user has a fixed version of the control on their system, a renamed / signed DLL or OCX served from a malicious web page could revert their machine to an insecure state.

    Additionally, the “Always trust content from…” checkbox on the Authenticode dialog box, if checked for a particular trusted publisher, could allow old / vulnerable signed versions of controls to install silently. Otherwise, the victim of such an attack would be presented with an Authenticode dialog from a presumably trustworthy publisher. Once the old / vulnerable control is installed, the attacker can immediately script to it.

    Kill-Bits are effective regardless of their origin but obviously wider distribution of a Kill-Bit ensures more comprehensive protection. If you would like Microsoft to distribute a Kill-Bit in Windows on your behalf, contact the MSRC and include details on the CLSID(s) in question.

    What is the relationship between an OBJECT tag’s CLSID and CODEBASE attributes?

    It is possible to specify any CLSID paired with any CODEBASE in an OBJECT tag. If that CLSID isn’t already registered, IE will attempt to download the control specified in the CODEBASE attribute of the OBJECT tag. It isn’t feasible for IE to know what control a package installs before that package is actually installed.

    Will controls with the Kill-Bit still load in other applications?

    Yes. See “What applications respect the Kill-Bit?” above.

    Is it still possible to download and install an ActiveX control with the Kill-Bit?

    Yes. Setting the Kill-Bit on a control only affects that control’s ability to instantiate within Kill-Bit aware hosts such as IE.

    - Security Vulnerability Research & Defense Bloggers

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

    Updates March 11, 2009 - updated blog post and flagged where updates were made.