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.