Kill-Bit 常见问题解答：第三部分

Microsoft 安全公告中经常包含“Kill-Bit”来禁用单个 ActiveX 控件 / COM 对象。以下是我们的三部分 Kill-Bit 常见问题解答的最后一部分。

Kill-Bit 常见问题解答 – 第三部分

是否存在可能使基于 Kill-Bit 的修复复杂化的问题？

是的。这里有一个有趣的例子：如果易受攻击的代码位于与实现 ActiveX 控件的二进制文件（由控件的注册 CLSID 引用的那个）不同的二进制文件中，那么 Kill-Bit 可能无法达到预期效果。

根据下图 1 的上半部分，假设控件 AX.1 引用了 DLL.1 中的某些易受攻击的代码。提议的修复计划如下：

• DLL.1 中的代码将被修复并作为 DLL.2 发布。
• 将为 AX.1 发布一个 Kill-Bit / Phoenix-Bit，以重定向到具有全新 CLSID 的 AX.2。
• 新的二进制文件 DLL.2 和 AX.2 将捆绑在一个修复包中。

现在假设旧的 DLL.1 二进制文件被放置到系统上并注册。系统现在处于“降级”和易受攻击的状态，如图 1 所示。Kill-Bit 不会自动解决这个问题，因为即使是新的“修复”后的 AX.2 仍然可以引用旧的易受攻击的 DLL.1。

因此，如果您需要修复一个易受攻击的控件，并且易受攻击的代码实际上位于一个单独的二进制文件中，请确保新控件无法使用旧的 / 易受攻击的二进制文件，即使该二进制文件被重新引入系统。您可以通过在新控件和新的 / 修复的二进制文件之间执行握手或版本检查来实现这一点。

在决定使用 Kill-Bit 之前，您应始终仔细考虑其适用性。例如，如果攻击向量存在于不支持 Kill-Bit 的应用程序中，那么 Kill-Bit 显然不会有效。请参阅第二部分中的“如果我 Kill-Bit 了我的易受攻击的对象 / 控件，我是否仍应发布修复版本？”。

感谢 Matt Thomlinson 提供上面的图 1！

我可以将我的 ActiveX 控件锁定到特定网站作为额外的安全措施吗？

是的，使用 SiteLock。尽量避免从头实现此功能 – 有很多方法会出错。

SWI 建议仅将 SiteLock 用作“深度防御”，因为它并非万无一失。（例如，如果域上存在跨站脚本漏洞，可能会被滥用绕过此限制。）

有哪些关于 ActiveX 控件的其他资源？

与本常见问题解答最相关的是：

• ActiveX 安全：改进和最佳实践
• 如何停止 ActiveX 控件在 Internet Explorer 中运行
• 设计安全的 ActiveX 控件
• ActiveX 控件的安全初始化和脚本编写
• 关于 Internet Explorer 的 IObjectSafety 扩展

其他有用的内容：

• 如何在 Visual Basic 控件中实现 IObjectSafety

• SafeCtl.exe 在 ActiveX 控件中实现 IObjectSafety

• 信息：从 ActiveX 控件内部访问对象模型

• IE 博客关于 ActiveX 控件的 SiteLock 模板的条目

• 信息：OLE 控件和 ActiveX 控件之间的区别

• OLE 控件和控件容器指南，版本 1.1

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