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.

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:

• ActiveX Security: Improvements and Best Practices
• How to stop an ActiveX control from running in Internet Explorer
• Designing Secure ActiveX Controls
• Safe Initialization and Scripting for ActiveX Controls
• About IObjectSafety Extensions for Internet Explorer

Other good stuff:

• How To Implement IObjectSafety in Visual Basic Controls
• SafeCtl.exe implements IObjectSafety in ActiveX control
• INFO: Accessing the Object Model from Within an ActiveX Control
• IE Blog Entry on SiteLock Template for ActiveX Controls
• INFO: Difference Between OLE Controls and ActiveX Controls
• OLE Controls and Control Containers Guidelines, Version 1.1

- Security Vulnerability Research & Defense Bloggers

(責(zé)任編輯：admin)

• ·注冊ActiveX控件的幾種方法
• ·在Access2003或以上版本使用RichTX32.O
• ·快速注冊DLL和OCX的方法【技巧】
• ·Access的Treeview在 MS10-036 更新后無
• ·在安全補(bǔ)丁Security Advisory 960715
• ·Access2010使用Treeview出現(xiàn)問題的解決
• ·Access中使用TreeView 樹形控件 詳細(xì)講
• ·Access中treeview不能使用或提示沒有版
• ·The Kill-Bit FAQ: Part 3 of 3
• ·The Kill-Bit FAQ: Part 2 of 3
• ·The Kill-Bit FAQ: Part 1 of 3
• ·ACCESS EXCEL 一個增強(qiáng)Treeview 節(jié)點(diǎn)編
• ·windows 7或其它windows 64位系統(tǒng)里Tre
• ·Access Treeview 樹控件MSCOMCTL.OCX
• ·[技巧]如何導(dǎo)出Imagelist的圖標(biāo)或圖片
• ·Access中使用身份證讀卡器的技巧