运行时二进制微补丁：为废弃的 Equation Editor 注入安全修复

废弃组件的安全困境

Microsoft Office 的 Equation Editor（EQNEDT32.EXE）是一个诞生于 2000 年的古老组件，其 PE 头中的时间戳显示编译日期为 2000 年 11 月 9 日。这个 17 年未更新的可执行文件在 2017 年被发现存在严重的缓冲区溢出漏洞 CVE-2017-11882，攻击者可通过构造恶意的 RTF 文档触发远程代码执行。

问题的复杂性在于：Microsoft 早已在 Office 2007 之后集成了新的公式编辑器，但由于向后兼容性的考虑，旧版 EQNEDT32.EXE 仍被保留以支持编辑历史文档。这意味着即使官方发布了补丁，大量遗留系统仍然面临风险，尤其是在企业环境中，升级或替换组件往往涉及复杂的审批流程和兼容性测试。

漏洞机理：无边界字符串拷贝

CVE-2017-11882 的根源位于 EQNEDT32.EXE 中地址 4164FA 处的函数。该函数负责将用户提供的字体名称字符串逐字符拷贝到内部缓冲区，但原始实现中完全没有检查目标缓冲区的大小限制。当字体名称超过缓冲区容量（通常为 0x20 字节或 0x100/0x1F4 字节）时，就会发生栈溢出，攻击者可以覆盖返回地址并劫持程序执行流。

Embedi 团队的研究表明，通过精心构造的 OLE 对象，可以在 Equation Editor 进程中执行任意代码。这种攻击向量特别危险，因为 Office 文档是日常办公中最常见的文件交换格式，用户往往在不知情的情况下打开恶意文档。

Microsoft 的手动二进制补丁

面对这个古老组件，Microsoft 选择了一种非常规的修复方式：直接手动修改二进制可执行文件，而非从源代码重新编译。通过 BinDiff 对比分析可以发现，补丁后的版本（2017.8.14.0）与原始版本（2000.11.9.0）相比，所有函数的内存地址完全一致，这只有在直接编辑二进制而非重新编译的情况下才可能发生。

Microsoft 的工程师在函数 4164FA 处注入了一个额外的参数用于传递缓冲区长度，并修改了字符拷贝循环的逻辑，使其在达到源字符串结尾或目标缓冲区上限时停止。同时，在缓冲区末尾显式添加空字符终止，防止未终止字符串导致的后续问题。为了腾出空间注入这些指令，补丁作者甚至优化了原有的 memcpy 实现，将双字（movsd）拷贝改为单字节（movsb）拷贝，牺牲了极小的性能换取代码空间。

此外，补丁还在另外两处函数（41160F 和 4219F0）中插入了六个类似的边界检查， proactively 封堵了其他潜在的缓冲区溢出攻击向量。最后，Microsoft 还启用了 ASLR（地址空间布局随机化）标志，使利用固定地址的漏洞利用更加困难。

0patch 的微补丁方案

与 Microsoft 的磁盘级二进制补丁不同，0patch 提供了一种运行时微补丁（micropatching）方案。其核心组件 0patch Agent 作为一个驻留服务监控所有运行的进程，当检测到存在漏洞的 EQNEDT32.EXE 被加载时，自动将微补丁代码注入到进程的地址空间中。

这种技术的优势在于：

非侵入式修复：微补丁仅修改内存中的进程映像，不触碰磁盘上的原始可执行文件。这意味着不需要重新签名二进制，也不会影响文件的哈希值，避免了与某些安全软件或合规审计的冲突。

即时生效：补丁在进程启动时自动应用，无需重启计算机或重新启动应用程序。对于正在运行的 Equation Editor 实例，补丁同样可以在下一次启动时生效。

空间灵活性：与手动二进制补丁需要在原始代码空间内腾挪不同，0patch 的微补丁可以分配新的内存区域存放补丁代码，通过跳转指令将执行流重定向到安全代码，再返回原逻辑。这种自由度使得补丁开发更加高效，不需要像 Microsoft 那样精心优化指令以节省空间。

遗留系统支持：对于已经停止官方支持的软件版本（如 Office 2010 或 Windows 7），0patch 可以继续提供安全修复，填补官方补丁空白期。

技术实现要点

在实现层面，0patch 的微补丁技术涉及以下关键环节：

地址空间注入：通过 Windows 的进程间内存操作 API，将补丁代码写入目标进程的虚拟地址空间。这通常需要在目标进程中分配可执行内存页，并确保补丁代码的位置不会与原始代码或数据冲突。

指令级修复：针对 CVE-2017-11882，0patch 的微补丁在函数入口处插入边界检查逻辑，验证输入字符串长度是否超过目标缓冲区容量。如果检测到溢出风险，立即终止危险操作并返回错误码，阻止恶意输入到达漏洞代码路径。

执行流重定向：使用短跳转（short jump）或近跳转（near jump）指令将原始函数的执行流重定向到补丁代码。补丁执行完成后，再跳转回原函数的后续逻辑，确保程序行为的一致性。

原子性保证：补丁的应用是原子操作，确保在注入过程中不会出现指令执行到一半的状态，防止进程崩溃。

部署与限制

在实际部署中，0patch Agent 需要以系统服务形式运行，并定期连接 0patch 服务器检查新补丁。企业用户可以通过 0patch Central 进行集中管理，将计算机分组并设置不同的补丁策略，例如在测试组自动应用新补丁，在生产环境等待人工审批。

然而，这种技术也存在固有局限：

• 运行时依赖：微补丁仅在 0patch Agent 运行且进程处于活动状态时生效。如果 Agent 被停止或进程在补丁应用前已启动，保护将失效。
• 非持久化：补丁不修改磁盘文件，因此每次进程重新启动都需要重新应用补丁。
• 兼容性风险：虽然微补丁经过测试，但某些特定配置或定制化软件版本可能出现意外行为。
• 不能替代官方补丁：微补丁应被视为临时缓解措施或遗留系统的补充保护，而非官方补丁的完全替代品。

结论

CVE-2017-11882 案例展示了二进制微补丁技术在应对遗留软件安全漏洞时的独特价值。Microsoft 的手动二进制补丁证明了即使在源代码不可用的极端情况下，仍然可以通过精细的逆向工程修复漏洞；而 0patch 的运行时微补丁则提供了一种更加灵活、无需重启、对生产环境影响最小的修复方案。

对于维护大量遗留系统的企业而言，微补丁技术提供了一条在官方支持终止后仍能维持安全基线的可行路径。然而，安全团队应当清醒认识到，这本质上是一种风险缓解措施，长期而言，升级或替换存在已知漏洞的组件仍然是更根本的解决方案。

参考来源

• 0patch Blog: "Did Microsoft Just Manually Patch Their Equation Editor Executable? Why Yes, Yes They Did. (CVE-2017-11882)"
• Embedi Research: CVE-2017-11882 漏洞分析与 PoC

security