Kill-Bit常见问题解答：第二部分（共三部分）

微软安全公告中经常包含“Kill-Bits”来禁用单个ActiveX控件/COM对象。这是我们三部分Kill-Bit常见问题解答的第二部分。

ActiveX控件、OLE控件和COM对象之间的关系

ActiveX控件是一种旨在Web浏览器内使用的OLE控件。ActiveX控件可能被标记为“脚本安全”和“初始化安全”，并通过Authenticode进行签名打包。关于OLE和ActiveX控件区别的更多信息可在此处获取。

所有ActiveX/OLE控件都是COM对象，但反之则不成立。ActiveX/OLE控件基于COM构建，并实现所需的最小接口集，以便在任何OLE容器中正常运行。关于COM对象必须满足哪些要求才能被视为有效OLE控件的更多信息可在此处找到。

ActiveX控件、OLE控件和COM对象都可以在IE中使用OBJECT标签或通过脚本（“new ActiveXObject”等）实例化。所有这些都受“脚本安全”、“初始化安全”和Kill-Bit的约束。

IE是否会托管任何ActiveX控件、OLE控件或COM对象？

某种程度上是。在MS05-052之前，IE对所有COM对象一视同仁。任何已注册的COM对象只要其CLSID没有设置Kill-Bit，就可以在浏览器中实例化。“脚本安全”和“初始化安全”只有在实例化后，当尝试对对象进行特定操作时才会进行验证。想一想——如果不实际实例化控件，就无法调用控件的IObjectSafety实现！

在MS05-052中，IE进行了一项更改，影响了在Internet区域中实例化控件的方式。IObjectSafety检查现在被前置，以便IE可以快速确定控件安全状态，并在控件被识别为不安全时立即中止实例化。实例化时对COM对象进行额外不必要的探测是许多COM对象实例化漏洞可利用性的一个促成因素。控件作者可以在其控件上设置兼容性标志值0x00800000，以在必要时选择退出此新行为。

Kill-Bit如何与“脚本安全”和“初始化安全”（SFS/SFI）交互？

Kill-Bit优先于SFS/SFI。如果控件设置了Kill-Bit，它就不会在支持Kill-Bit的应用程序中加载，句号。

如果我为易受攻击的对象/控件设置了Kill-Bit，是否还应发布修复版本？

如果您为易受攻击的对象发布Kill-Bit，发布代码修复也是有意义的。代码修复将减轻通过不支持Kill-Bit的环境提供攻击场景所带来的威胁。如果您同时发布修复版本和Kill-Bit，请确保为控件提供新的CLSID，并在更新控件必须在支持Kill-Bit的环境中运行时根据需要发布“Phoenix-Bit”（见下文）。

什么是“Phoenix-Bit”（又名AlternateCLSID）？

由于Kill-Bit完全阻止控件在浏览器中加载，因此需要一种安全地修订控件而不破坏引用已杀死CLSID的Web内容的方法。Phoenix-Bit实现了这一点——它允许控件开发者杀死易受攻击的CLSID，并将对旧CLSID的请求透明地重定向到新的CLSID。“Phoenix-Bit”这个名字致敬了神话中以其再生能力闻名的凤凰鸟。

在验证CLSID是否已被杀死时，MSHTML将检查是否为被杀死的CLSID提供了替代CLSID。这将允许未修订以引用新CLSID的页面或支持Kill-Bit的应用程序仍然正常运行。

要实现Phoenix-Bit，请在ActiveX Compatibility键下的被杀死的CLSID中添加一个“AlternateCLSID”字符串值。Phoenix-Bit要求同时设置Kill-Bit。示例：

1
2
3
4

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

警告 - 如果使用注册表编辑器或其他方法错误地修改注册表，可能会发生严重问题。这些问题可能需要重新安装操作系统。修改注册表的风险自负。

替代CLSID需要花括号。可以链式重定向多达十层。

Phoenix-Bit在IE6 SP1中引入，并在2003年向后移植到下级版本（5.01和5.5）。它在所有完全打补丁的IE >= 5.01版本上都受支持。

如果我实现Phoenix-Bit，控件是否还应支持旧CLSID？

如果控件旨在在IE之外托管，那么是的。在这种情况下，控件应同时支持旧CLSID和新CLSID。否则，不理解或不遵守Phoenix-Bit的主机如果通过旧CLSID引用控件将会被破坏。

Phoenix-Bit有哪些替代方案？

如果控件的现有CLSID在许多网页中硬编码，放弃它可能很困难。此问题的推荐解决方案是Phoenix-Bit（见上文）。除了Phoenix-Bit，您可能还想研究一些潜在的替代解决方案：

• TreatAs类似于Phoenix-Bit，但适用于特定对象的任何客户端，而不仅仅是MSHTML或其他支持Kill-Bit/Phoenix-Bit的应用程序。像这样设置TreatAs：

  1	HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CLSID}\TreatAs =<CLSID_TreatAs>

  TreatAs在此处有文档记录。

• 如果易受攻击的对象从未作为签名的DLL/OCX、在签名的CAB中或在签名的可执行安装程序中发布，可能不需要设置Kill-Bit。在没有签名包的情况下，网页不可能如上所述将旧的/易受攻击的签名控件强加给用户（参见“为什么我的易受攻击控件/对象需要Kill-Bit？”）。

• 软件发布者证书吊销。

• 可能通过对底层平台进行更改来有效杀死控件，该更改会破坏旧控件，同时仍允许新控件正常加载。该更改需要在潜在漏洞被利用之前影响控件的加载能力。例如，想象一下将特定注册表键设置为无效值会导致控件在初始化之前中止。设置此键可以有效地阻止旧的/易受攻击的控件版本加载，而新的/修复的控件版本可以忽略无效值。

• Internet Explorer实现了一种基于哈希阻止下载/安装特定签名二进制文件的机制。哈希存储在HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\Restriction Policies\Hashes下。

• 管理员可以使用管理员批准的控件功能提供将运行的特定控件列表。

用户是否有简单的方法在Internet Explorer中阻止ActiveX控件而不设置Kill-Bit？

是的，XP SP2及更高版本中的加载项管理器允许用户轻松禁用Internet Explorer中的特定ActiveX控件。但值得一提的是，这在技术上并不等同于设置Kill-Bit。例如，尊重Kill-Bit以阻止ActiveX控件的Windows应用程序可能尊重也可能不尊重加载项管理器设置。

• 安全漏洞研究与防御博客作者 发布内容“按原样”提供，不提供任何担保，也不授予任何权利。