Kill-Bit 技术详解:ActiveX 控件禁用机制与注册表配置

本文详细介绍了Kill-Bit的作用机制,包括如何通过注册表设置禁用特定CLSID的ActiveX控件,以及Kill-Bit在IE浏览器和Office文档中的生效范围。同时解释了为何需要发布Kill-Bit来防止旧版漏洞控件被恶意利用。

Kill-Bit 常见问题解答:第一部分(共三部分)

微软安全公告中经常包含“Kill-Bit”来禁用单个ActiveX控件/COM对象。以下是我们开发的三部分FAQ的第一部分,解答有关Kill-Bit及相关功能的一些问题。

Kill-Bit 常见问题解答 – 第一部分(共三部分)

什么是Kill-Bit?

Kill-Bit(又称“killbit”)实际上不是一个位。Kill-Bit是特定CLSID的注册表项,用于标记该CLSID引用的COM对象/ActiveX控件在浏览器和其他可编写脚本的环境中不可加载。微软通过安全更新发布Kill-Bit,以阻止在浏览器中托管时存在安全漏洞的易受攻击的ActiveX控件和COM对象。

对控件发布Kill-Bit会标记该特定控件在浏览器中禁止实例化。通过按照KB文章240797中的描述,在注册表中将控件的兼容性标志值设置为0x400来发布Kill-Bit。

Kill-Bit在注册表中的位置?

Kill-bit位于注册表中:

  • 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

(2009年3月11日更新:添加了x86/x64场景的详细信息)

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

请注意,并非此位置中列出的所有CLSID都被禁用,只有包含兼容性标志DWORD值0x400的控件才会被禁用。兼容性标志的可接受值在此处有文档记录。

如果您正在设置Kill-Bit,您可能需要确保不会清除被禁用CLSID的任何现有兼容性标志。如果您要删除CLSID,为了保留任何预先存在的兼容性标志,从兼容性标志DWORD值中减去0x400,并且仅在兼容性标志值恰好设置为0x400时才删除CLSID键。

哪些应用程序遵守Kill-Bit?

Kill-Bit在Internet Explorer(所有区域)以及Microsoft Office场景中(对象嵌入文档中)得到遵守。Kill-Bit默认也应在任何其他托管IE浏览器渲染引擎(MSHTML)的应用程序或平台中生效。一个显著的例外是HTA – 使用HTA时,已经可以加载不安全的控件并运行任意代码。HTA是一种不安全的文件类型。

(2009年3月11日更新:HTA目前确实遵守通过OBJECT标签实例化的对象的Kill-Bit。当HTA在脚本中实例化对象时,Kill-Bit不被遵守。感谢Nicolas Noakes报告此问题。HTA中的Kill-Bit行为将来可能会变得更加一致。)

可以想象,一个控件可能存在如此严重的缺陷,以至于Kill-Bit无法有效阻止所有攻击向量。例如,假设一个控件被发现实现了一个Web服务器,该服务器在负责解析Web请求的代码中存在缓冲区溢出。在这种情况下,必须发布代码修复 – 仅仅实施Kill-Bit无法提供全面的解决方案,因为任何使用该控件的应用程序都会暴露于漏洞。

如果一个应用程序或平台托管控件并允许这些控件有效地由不受信任的数据驱动,则该环境应遵守安全脚本、安全初始化和Kill-Bit逻辑。否则,环境应提供其他同等或更严格的策略,例如已知良好可编写脚本对象的允许列表。

为什么我的易受攻击的控件/对象需要Kill-Bit?

必须发布Kill-Bit以防止旧的/易受攻击的签名版本控件被有效地强加给用户。即使用户系统上安装了固定版本的控件,从恶意网页提供的重命名/签名的DLL或OCX可能会将其机器恢复到不安全状态。

此外,Authenticode对话框上的“始终信任来自…”复选框,如果为特定受信任发布者选中,可能会允许旧的/易受攻击的签名版本控件静默安装。否则,此类攻击的受害者将收到来自 presumably 可信发布者的Authenticode对话框。一旦旧的/易受攻击的控件安装,攻击者可以立即对其进行脚本编写。

Kill-Bit无论其来源如何都有效,但显然Kill-Bit的更广泛分发确保了更全面的保护。如果您希望微软代表您在Windows中分发Kill-Bit,请联系MSRC并包括有关相关CLSID的详细信息。

OBJECT标签的CLSID和CODEBASE属性之间有什么关系?

可以在OBJECT标签中指定任何CLSID与任何CODEBASE配对。如果该CLSID尚未注册,IE将尝试下载OBJECT标签的CODEBASE属性中指定的控件。IE在包实际安装之前知道包安装什么控件是不可行的。

带有Kill-Bit的控件是否仍会在其他应用程序中加载?

是的。请参阅上面的“哪些应用程序遵守Kill-Bit?”。

是否仍然可以下载并安装带有Kill-Bit的ActiveX控件?

是的。对控件设置Kill-Bit仅影响该控件在支持Kill-Bit的主机(如IE)中实例化的能力。

  • 安全漏洞研究与防御博客作者 发布内容“按原样”提供,不提供任何保证,也不授予任何权利。 更新于2009年3月11日 – 更新了博客文章并标记了更新位置。
comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计