The Kill-Bit FAQ: Part 3 of 3

原文: http://blogs.technet.com/b/srd/archive/2008/02/08/the-kill_2d00_bit-faq_3a00_-part-3-of-3.aspx

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:

Other good stuff: