Security Research & Defense

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

February, 2008

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

  • The Kill-Bit FAQ: Part 2 of 3

    It is very common for Microsoft security bulletins to include “Kill-Bits” to disable individual ActiveX controls / COM objects. Here is the second part of our three-part Kill-Bit FAQ.

    The Kill-Bit FAQ – Part 2 of 3

    How do ActiveX Controls, OLE Controls, and COM Objects relate?

    An ActiveX control is an OLE control that is intended to be used inside a web browser. Likely an ActiveX control is marked Safe for Scripting and Safe for Initialization as well as being packaged to be installed via Authenticode. More information on the difference between OLE and ActiveX controls is available here.

    All ActiveX / OLE controls are COM objects, but not vice versa. ActiveX / OLE controls are built on COM and implement a required minimum set of interfaces in order to operate properly within any OLE container. More information on the requirements that a COM object must meet in order to be considered a valid OLE control can be found here.

    ActiveX Controls, OLE Controls, and COM Objects all can be instantiated in IE with an OBJECT tag or through script (“new ActiveXObject”, etc.) All are subject to Safe for Scripting, Safe for Initialization and the Kill-Bit.

    Will IE host any ActiveX Control, OLE Control, or COM Object?

    Sort of. Prior to MS05-052, IE treated all COM objects equally. Any registered COM object could be instantiated within the browser just as long as the Kill-Bit wasn’t in place for its CLSID. Safe for Scripting and Safe for Initialization would be verified only after instantiation as particular operations were attempted on the object. Think about it – there’s no way to call into a control’s implementation of IObjectSafety without actually instantiating the control!

    In MS05-052, IE made a change that affects the way controls are instantiated in the Internet zone. The IObjectSafety check is now frontloaded so that IE can determine control safety status quickly and abort instantiation as soon as a control is identified as unsafe. Extra unnecessary probing of COM objects upon instantiation was a contributing factor to the exploitability of many COM object instantiation bugs. Control authors can set the compatibility flag value of 0x00800000 on their controls to opt-out of this new behavior if necessary.

    How does the Kill-Bit interact with “Safe for Scripting” and “Safe for Initialization” (SFS / SFI)?

    The Kill-Bit trumps SFS / SFI. If a control has the Kill-Bit, it just won’t load within Kill-Bit aware applications, period.

    If I Kill-Bit my vulnerable object / control, should I still release a fixed version?

    If you are releasing a Kill-Bit for a vulnerable object, it makes sense to issue a code fix as well. A code fix will mitigate the threat posed by environments that provide an attack scenario through which the vulnerability can be exploited yet do not support the Kill-Bit. If you do release a fixed version as well as a Kill-Bit, make sure to give the control a new CLSID and issue a “Phoenix-Bit” (see below) as necessary if the update control must operate within Kill-Bit aware environments.

    What is the “Phoenix-Bit” a.k.a. AlternateCLSID?

    Since a Kill-Bit completely prevents a control from loading in the browser, there needs to be a way to safely revise a control without breaking web content that references the killed CLSID. The Phoenix-Bit does this – it allows control developers to kill the vulnerable CLSID and transparently redirect requests for the old CLSID to a new CLSID. The name “Phoenix-Bit” honors the mythical Phoenix bird known for its regenerative ability.

    When verifying that a CLSID has or has not been killed, MSHTML will check to see whether an alternate CLSID has been provided for use in place of a killed CLSID. This will allow pages or Kill-Bit aware applications that have not been revised to refer to the new CLSID and still function.

    To implement the Phoenix-Bit, add an “AlternateCLSID” string value to the killed CLSID under the ActiveX Compatibility key. The Phoenix-Bit requires that the Kill-Bit is also set. Example:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\

    {CLSID of killed ActiveX control}, Compatibility Flags, 0x0400

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\

    {CLSID of killed ActiveX control}, AlternateCLSID, “{CLSID of alternate ActiveX control}”

    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.

    The alternate CLSID requires the curly braces. It is possible to chain redirects up to ten levels deep.

    The Phoenix-Bit was introduced in IE6 SP1 and was backported to downlevel versions (5.01 and 5.5) in 2003. It is supported on all fully patched versions of IE >= 5.01.

    If I implement the Phoenix-Bit should the control still support the old CLSID?

    If the control is intended to be hosted outside of IE, then yes. In that case the control should support both the old CLSID and the new CLSID. Otherwise, hosts that do not understand or honor the Phoenix-Bit will be broken if they reference the control by the old CLSID.

    Are there any alternatives to the Phoenix-Bit?

    Ditching your control’s existing CLSID may be difficult if the CLSID is hard-coded in many web pages. The recommended solution to this problem is the Phoenix-Bit (see above). Besides the Phoenix-Bit, there are a few potential alternate solutions you may want to investigate:

    • TreatAs is similar to the Phoenix-Bit but applies to any client of a particular object rather than just MSHTML or other Kill-Bit / Phoenix-Bit aware applications. Set TreatAs like this:
      HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CLSID}\TreatAs = <CLSID_TreatAs>
      TreatAs is documented here.
    • It may not be necessary to Kill-Bit a vulnerable object if it was never shipped as a signed DLL / OCX, within a signed CAB, or within a signed executable installer. In the absence of a signed package it won’t be possible for a web page to foist an old / vulnerable signed control onto users as described above (see “Why does my vulnerable control / object need a Kill-Bit?”).
    • It may be possible to effectively kill a control by making a change to the underlying platform that breaks the older control while still allowing the new control to load properly. The change would need to affect the control’s ability to load before the potential vulnerability can be exploited. For example, imagine that setting a particular registry key to an invalid value causes a control to abort before initializing. Setting this key could effectively block the old / vulnerable versions of the control from loading while a new / fixed version of the control could ignore the invalid value.
    • Internet Explorer has implemented a mechanism to block download / installation of specific signed binaries based on their hash. Hashes are stored under HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\Restriction Policies\Hashes.

    Is there an easy way for users to block ActiveX controls in Internet Explorer without setting a Kill-Bit?

    Yes, the Add-on Manager in XP SP2 and above allows users to easily disable specific ActiveX controls in Internet Explorer. It’s worth mentioning though that this is not technically equivalent to setting a Kill-Bit. So for example, Windows applications that respect the Kill-Bit to block ActiveX controls may or may not respect the Add-on Manager settings.

    - Security Vulnerability Research & Defense Bloggers

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

  • The Kill-Bit FAQ: Part 3 of 3

    It is very common for Microsoft security bulletins to include “Kill-Bits” to disable individual ActiveX controls / COM objects. Here is the final part of our three-part Kill-Bit FAQ.

    The Kill-Bit FAQ – Part 3 of 3

    Are there issues that could complicate the implementation of a Kill-Bit based fix?

    Yes. Here’s one interesting example: if the vulnerable code is in a separate binary from the one that implements the ActiveX control (the one referenced by the registered CLSID for the control) then the Kill-Bit may not have the intended effect.

    Per the top portion of Figure 1 below, imagine Control AX.1 references some vulnerable code in DLL.1. The proposed fix plan is as follows:

    • The code in DLL.1 will be fixed and released as DLL.2.
    • A Kill-Bit / Phoenix-Bit will be released for AX.1 to redirect to AX.2 which has a brand new CLSID.
    • The new binaries, DLL.2 and AX.2, will be bundled together in one fix package.

    Now imagine that the old DLL B.1 binary is dropped onto the system and registered. The system is now in a “downgraded” and vulnerable state, as depicted in Figure 1. The Kill-Bit does not automatically address this problem because even the new “fixed” AX.2 can still reference the old vulnerable DLL.1.

     

    image

    Figure 1

    Consequently, in the event that you need to fix a vulnerable control and the vulnerable code is actually in a separate binary, make sure that the new control is not able to use the old / vulnerable binary even if that binary is reintroduced onto the system. You can achieve this by performing a handshake or version check between the new control and the new / fixed binary.

    You should always carefully consider the applicability of the Kill-Bit before deciding to use it. For example, if an attack vector exists through a non-Kill-Bit-aware application then a Kill-Bit obviously will not be effective. See “If I Kill-Bit my vulnerable object / control, should I still release a fixed version?” in part 2.

    Thanks to Matt Thomlinson for providing Figure 1 above!

    Can I lock my ActiveX control down to a specific web site as an additional security measure?

    Yes, use SiteLock. Try to avoid implementing this functionality from scratch – there are many ways to get this wrong.

    SWI recommends using SiteLock only as “defense-in-depth” as it is not bulletproof. (For example, if a Cross-Site Scripting flaw exists anywhere on the domain it can potentially be abused to bypass this restriction.)

    Where are some additional resources on ActiveX Controls?

    Most relevant to this FAQ:

    Other good stuff:

    - Security Vulnerability Research & Defense Bloggers

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