如何修复修复中的错误

2026-Oct-06 Natalie Silvanovich

Project Zero 经常与软件厂商合作修复我们报告的漏洞，并就如何让软件更安全提供更广泛的指导。有些厂商担心，一旦出现漏洞正在对用户造成直接伤害、而他们的补丁分发系统又力有不逮的情况，他们将无法完成修复。在与厂商的沟通以及安全审查中，Project Zero 见过各式各样的系统，用于在异常利用场景下保护用户，因此我们想分享一些经验。

本文概述大型厂商正在使用的一类系统，它们能以远快于常规更新流程的速度修复少量漏洞。我们的目标是为希望搭建或增强此类系统能力的厂商提供参考，并促使厂商在收到紧急漏洞之前，就想清楚自己会怎么修。

为什么打补丁需要时间

修复一个漏洞通常要经过以下阶段：

• 分诊——收到漏洞报告，完成验证、排定优先级，并指派给具体的开发者修复
• 补丁开发——软件开发团队编写、评审并提交修复该漏洞的代码
• 测试——验证补丁是否消除了漏洞，以及打上补丁后软件是否仍能正常工作。这可能包括测试团队的正式测试、自动化测试，以及将补丁推送给少量用户、收集正常使用反馈的 alpha 和 beta 测试。
• 合作方审核——由于软件厂商与其他组织之间的关系，某些软件更新在发布前需要第三方审核，例如部分移动端更新需要运营商验收。
• 分发——补丁送达终端用户并由其安装
• 激活——有时还需要额外一步，比如重启系统，才能切换到更新后的软件

当然，这只是简化后的图景。打补丁可能涉及重复步骤，比如测试失败后重写补丁，或者在涉及第三方供应商时增加额外阶段。不过，这已经是大多数软件更新所需的最小步骤集合。

紧急补丁的挑战

分诊和补丁开发时间在很大程度上决定了厂商通常能以多快的速度修复漏洞，但对紧急补丁的耗时影响较小。当厂商知道自己面对的是紧急问题时，分诊通常非常快，补丁开发也可以根据优先级加速推进。只有在极少数情况下——漏洞特别复杂，或者厂商的安全团队对自家软件的组件以及组织内部由谁维护这些组件没有完整掌握——我们才会看到紧急补丁在分诊或开发阶段被拖延。同样，合作伙伴协议通常也会对紧急情况下的更新设有例外条款。

大多数厂商的补丁速度受限于测试和交付阶段。测试之所以重要，是因为对软件的任何改动都可能引入意外行为。最坏的情况是测试不充分的软件把设备“变砖”，使其无法正常运行，既不能执行关键功能，也无法接收软件更新来修复。有缺陷的软件更新还曾导致用户数据损坏或丢失，而安全更新后软件功能出现任何下降，都会让用户将来更不愿意安装更新。

发布测试不充分的更新，厂商可能付出的代价因底层软件的性质而异。例如，如果一款移动应用因为更新损坏了本地数据或无法启动而变得不可用，用户可以轻松通过应用商店安装下一个版本，数据通常也保存在远程服务器上，所以代价仅限于用户支持。而如果移动设备变砖，就需要送回制造商或购买处维修，这会给厂商乃至用户带来可观的成本。

大多数补丁分发系统在设计时都会考虑到出现严重功能性 bug 的可能。更新往往分批缓慢推送，这样严重问题在影响到过多用户之前就能被发现。快速修补漏洞与避免推送有 bug 的补丁常常相互冲突，需要在两者之间做出取舍，优先保证其中一方。

还有各种技术难题会拖慢补丁分发的速度。其中之一是补丁系统的设计。常见的设计是设备按固定间隔轮询更新，补丁饱和度因此受限于这个间隔。“推送”式更新系统能更快地把补丁送达所有用户，但通常需要更多基础设施。

用户行为和使用环境也可能阻碍补丁传播。需要用户交互才能安装的补丁常被用户拖延，网速和数据费用也会影响安装率。一次性更新大量用户（而非在一段时间内分批推送）会给补丁分发基础设施带来压力。Chrome 和 Microsoft 都曾 撰文谈过需要重启才能安装的更新所带来的挑战，因为用户往往不愿重启系统，而重启本身也耗时。

测试延迟和补丁分发系统的局限会影响所有更新，但紧急更新的时间窗口更短，因此在补丁送达所需的总时间中占比更大。

紧急修补方法

功能开关

功能开关是源码中的条件语句，其分支由远程服务器提供的值决定。它们常用于 A/B 测试，但在紧急情况下也可用于漏洞的短期补救。一个广为人知的案例是 2019 年 FaceTime 的一个严重漏洞，Apple 当时用功能开关临时禁用了 Group FaceTime。多家厂商已将至少部分可在 0-click 场景下触发的媒体编解码器改为由功能开关控制，在遭到实际利用时可以将其禁用，实时传输则回退到另一种编解码器。

特性开关作为一种漏洞修复手段，主要好处在于可以针对每一种开关状态提前完成测试，因此快速更新时无需发布未经测试的代码。特性开关的推送速度也快得多，因为更新开关只需要传输极少量的数据。

最近，Meta 发布了一篇博客文章，介绍他们如何实现一个“双栈”库：把两个版本的 WebRTC 视频会议库编译进同一个二进制文件，通过特性开关控制当前使用哪一个版本。这项技术让快速更新所需的测试量更少，因为新版本发布时可以保留一个选项，一旦出现功能问题就迅速把用户切回旧版本。Meta 用的是同一个库的两个版本，但也可以用两个实现相同功能的不同库（比如两个 H264 库）来构建“双栈”，这样在紧急情况下，应用可以切换到另一个库，让某个特定漏洞无法被触达，同时不损失任何功能。这需要额外的测试，但这些测试可以提前完成。还可以准备第二个库，用来启用一些性能开销较大的缓解措施，比如 ASAN 或开启 DCHECK，从而挡住许多可能的 bug。

过滤

过滤是指用一套可动态更新的规则集（例如正则表达式）来检查不可信输入，以拦截触达某个漏洞所必需的特定输入。Android 的 Intent Firewall 就是一个例子：它允许根据一个可动态更新的 XML 文件中的规则，禁用对 Android IPC 机制 intent 的特定用法，从而拦截那些可被用来触发特定漏洞的 intent。它最近被用来拦截第三方 Android 钱包中的漏洞。

有些平台自带端点检测软件，能对多种系统输入进行过滤，例如 Windows 系统上的 Microsoft Defender 和 Android 设备上的 Google Play Protect。拦截特定 exploit 或让某些漏洞无法被触达的规则，通常可以很快部署到这些应用上。端点检测需要解析大量不可信输入，而且往往在特权上下文中进行，因此这些应用本身并非没有风险；但在已经部署了这类应用的系统上，它们是应急修复的一种可行手段。

作为一种手段，过滤比功能开关更灵活。功能开关要起作用，厂商必须事先确定自己可能想关掉哪些功能；一旦考虑得不够周全，就可能陷入漏洞无法通过功能开关修复的境地。而过滤可以用来拦截各种各样的输入，哪怕是此前从未被考虑过的。过滤的缺点在于：频繁过滤会拖累软件性能；新过滤器至少需要经过一定测试，而在不知道要拦截哪个漏洞的情况下，这部分测试无法提前完成；此外，过滤器有可能写错，干扰系统必需的功能。

备用通道

用于向用户分发软件更新的网络“通道”可能因上文讨论的各种原因而速度缓慢。厂商有时会搭建备用通道，用来更快地分发体积较小的更新。

Android Pony Express（APEX）就是这样一种备用通道，它可以比整包系统更新更快地把更新推送到 Android 中特定的高风险组件。由于 OEM 无需再集成 APEX 组件的更新，补丁开发时间得以缩短。APEX 已向 OEM 开放，可用于更新由 OEM 维护的库。

我们研究过的几款应用能够在常规更新之外单独更新某些库，通常的做法是设置一个标志位，定期通过网络检查，然后下载对应的库并用 dlopen 或同类机制加载。这确实是绕开更新分发速度限制的有效办法，但如果以这种方式下发的库没有在客户端得到充分校验、无法确认来自厂商，也可能引入严重漏洞。我们建议厂商保持谨慎，确保这类应急更新机制经过充分的安全测试。

热补丁

一些厂商已经实现了更新机制，可将比库更小的二进制代码单元直接投递到运行中进程的内存空间并加以应用。例如，Linux 支持 Livepatch，无需重启即可在内存中直接替换内核函数。Windows 的 hotpatch 同样如此，它允许将仅包含更新函数的补丁投递给用户，并在进程仍在运行时加以应用。

热补丁有望以极快的速度向软件投递非常灵活的安全补丁，且不损害用户体验，但它能投递的补丁在性质上通常有若干限制，比如需要修改函数间共享结构体定义的更新有时就不受支持。热补丁在安全上的弊端与替代更新通道类似，还带来引入绕过漏洞缓解措施的风险，因为打补丁的过程中某一时刻需要以可写可执行权限映射页面。它也没有解决快速更新在测试上的任何难题，只解决了投递难题。

紧急打补丁的重要性

LLM 正在同时提升攻击者和防御者发现与利用漏洞的能力。如今有更多类型的参与者能够以更快的速度实施新型攻击。有鉴于此，厂商必须考虑在漏洞遭到实际利用时如何保护用户。快速更新机制不必是重量级的，也不必能在任何场景下修复所有可能的 bug 并保持完美的用户体验。feature flag、过滤以及替代更新机制等技术可以在短期内修复最可能发生、最严重的漏洞，同时让设备对用户保持基本可用。

厂商亟需规划：在最坏情况下——漏洞被大规模实际利用——如何保护用户。现在采取的行动可以大幅改善用户的安全状况。盘点手中已有的更新机制，并在存在缺口的地方实现快速修复功能，厂商就能更好地应对未来的任何局面。

让零日漏洞利用难如登天。

---

隐私