Mozilla 的首要任务之一是保障用户安全；这一承诺体现在我们的使命中。一旦我们发现 Firefox 中存在严重问题，我们将计划快速进行缓解。本文将介绍我们如何通过全球跨职能团队（包括发布和质量保证工程师、安全专家和其他利益相关者）的协作和协调努力，在不到 22 个小时的时间内修复了 Pwn2Own 漏洞发现问题。

Pwn2Own 是一项年度计算机黑客竞赛。该活动的目的是找出主要软件（如浏览器）中的安全漏洞。上周，该活动在温哥华举行。本文不会详细介绍该漏洞的技术细节，而是将介绍 Mozilla 在 Pwn2Own 期间发现漏洞后如何迅速做出反应，发布 Firefox 的更新版本。

我们将分享一些使我们能够定期向数亿用户更新和发布 Firefox 浏览器新版本的流程。

这款浏览器是一个庞大的软件：1800 万行代码，6 个平台（Windows 32 位和 64 位、GNU/Linux 32 位和 64 位、Mac OS X 和 Android），90 种语言，再加上安装程序、更新程序等。发布这样一个庞然大物需要来自多个跨职能团队的许多人进行协调，这些团队遍布旧金山、费城、巴黎、罗马尼亚的克卢日和新西兰的兰吉奥拉等地。

Pwn2Own 活动的时间安排提前几周就已确定，因此 Mozilla 已做好准备！Firefox 火车发布日历 考虑到了 Pwn2Own 的时间安排。我们尽量避免在 Pwn2Own 当天向最终用户发布新的 Firefox 版本。

Firefox Chemspill

Chemspill 是“针对安全性的产品小版本”。这是 Mozilla 机器的内部名称，它在不利于浏览器稳定性或用户安全事件发生时，会在所有渠道（Nightly、Beta、Release、ESR）上生成 Firefox 的更新版本。

我们的快速响应模式类似于应急人员组织和动员处理化学品泄漏及其危害的方式。所有关键人员都停止当前的工作，只专注于清理工作本身。由于我们的重点是最终用户，因此我们需要确保他们使用的是最安全、最快的 Firefox 版本！

今年，我们在 Pwn2Own 之前创建了一个私人的 Slack 频道，用于协调与该活动相关的所有活动。最初的 Slack 团队只由安全专家、工程主管、高级工程师、发布经理和发布工程师组成——这是必不可少的员工。

我们提前准备了一份发布清单，添加了项目，并特别关注 Pwn2Own 触发的潜在 Chemspill。这份文档帮助跟踪跨职能任务、任务负责人、状态和截止日期，有助于跟踪单个任务以及必要的协调。它还有助于利益相关者实时查看和报告 Chemspill 状态。

我们安全团队的一名成员参加了 Pwn2Own 活动。在宣布参赛者之一 Richard Zhu 在 Firefox 中发现了安全问题后，这名 Mozilla 代表从 Richard Zhu 处直接收到了该漏洞，作为受影响供应商的 Pwn2Own 常规披露流程的一部分。该漏洞于 3 月 15 日太平洋标准时间上午 10:59 添加到我们的漏洞跟踪系统，并配有必要的隐私设置。不久之后，Chemspill 团队审查了该问题，并决定尽快发布更新版本。

与此同时，私人的 Slack 频道上也展开了讨论。当我们看到网络安全记者@howelloneill 发布的这条推特让新闻公之于众时，我们知道是时候确定负责修复漏洞的开发人员了……

于是，开发人员迅速开始工作。

修复：计划、风险分析、上线时间表

当工程师调查漏洞并想出解决办法时，发布更新版本的跨职能协调工作已经开始。Chemspill 团队在事件发生后 2 个小时内举行了会议。我们讨论了下一步措施，包括修复准备情况、测试计划、构建目标、质量保证签署以及确定步骤顺序和大致时间表。我们需要确保从北美人员到欧洲人员（法国、罗马尼亚、英国），然后在第二天早上再返回加州的顺利交接。

从我们获得有关该漏洞的信息那一刻起，就开始了两项并行的讨论：在漏洞跟踪系统上进行技术讨论；以及在 Slack 频道上进行由发布和安全经理推动的发布导向性讨论。

12 分钟后，在上午 11:11，相关开发人员接到了联系。

上午 11:17：更新漏洞信息，确认我们的长期支持版本 (ESR) 也受到了该问题的影响。
下午 12:32：在漏洞披露后不到 3 个小时，开发人员提供了解决该问题的第一个补丁。
下午 14:21：推送了修复程序的改进版本。
下午 15:23：该补丁已推送至开发分支。然后，在接下来的 70 分钟内，我们完成了将补丁合并到其他发布和预发布存储库的流程。

下午 17:16：在漏洞公布后不到 6 个小时，Beta 和 Release 版本（桌面版和 Android 版）正在构建中。

在构建阶段

让我们回顾一下每次发布新的 Firefox 版本时都会发生的常规工作流程。使用我们完整的测试套件构建适用于所有平台的 Firefox 浏览器大约需要 5 个小时。在构建过程中，许多团队都在并行工作。

测试计划

质量保证团队在工程的帮助下设计测试计划。在修复安全问题时，我们始终牢记两个目标

1. 验证修复程序是否解决了安全问题。
2. 找出由于修复导致的任何其他潜在的回归。

为了实现这两个目标，质量保证团队力求使用不同的输入来覆盖各种情况。

例如，以下测试用例 #3 已在各种受影响的版本和平台上执行

测试用例 3（ogg enabled false – 真实的 .ogg 文件）

• 选择一个频道
• 导航到 about:config
• 将 pref “media.ogg.enabled” 设置为 false
• 下载一个 .ogg 文件
• 将 .ogg 文件拖放到 Mozilla 构建中
• 观察错误消息/提示“您已选择打开 [文件名].ogg
• 尝试使用 Firefox 作为应用程序打开该文件
• 观察 Firefox 未播放选定的 .ogg 文件（或任何声音）
• 针对所有构建（ESR、RC、Beta/DevEdition、Fennec）重复步骤 1

漏洞分析

与此同时，我们的安全专家着手分析漏洞。

他们仔细观察了几方面

• 漏洞在技术上的运作机制
• 我们如何才能自行发现该问题
• 正在进行的工作：如何缓解此类攻击
• 停滞的工作：我们已经开始但尚未完成的工作
• 未来的工作：规划消除或缓解此类攻击的长远工作

外联

发现该漏洞存在于并非源自 Mozilla 项目的库中，该库也用于其他软件。由于我们不想0 日 该易受攻击的软件库，也不想让该漏洞更加广为人知，因此我们直接联系了该库的维护人员。然后，我们调查了哪些其他应用程序使用了这段代码，并尝试通知他们并让他们意识到该问题。

与此同时，我们与库维护人员合作，准备了一个新的独立库代码版本。

最后但并非最不重要的一点是，由于 GNU/Linux 发行版提供了该库的软件包，因此我们还将该问题告知了这些发行版。

构建完成后

大约 5 个小时后，构建工作完成。这时，质量保证团队开始执行测试计划。

他们验证了所有平台/操作系统上的所有场景。

在不到 22 个小时的时间里，也就是发现漏洞后不到一天的时间里，Mozilla 已经准备好在我们的 Nightly、Beta、ESR 和发布更新通道上为桌面版和 Android 版 Firefox 推送更新版本。

对于发布上线，安全团队编写了安全公告，并为CVE（通用漏洞和披露）创建了一项条目，该条目是一个公开列出已知网络安全漏洞的公开参考。

然后，在最后一刻，我们发现受影响代码的第二个变体，不得不重新构建 Android 版本。这也影响了 ARM 设备上的 Firefox ESR。我们在晚上 11:10 发布了此修复程序。

没有人愿意看到自己的产品被攻陷，但在软件开发中，就像许多事情一样，准备和协调可以决定 Chemspill 是否会造成任何损害，或者是否会成为一种潜在的危险情况。

通过多个分布式团队的共同努力，以及良好的规划和沟通，Mozilla 能够尽一切努力测试并发布漏洞修复程序，从而保障了全球用户的安全。我们认为这个故事值得分享。

相关资源

如果您有兴趣详细了解 Mozilla 的安全计划或 Firefox 安全问题，以下是一些资源可以帮助您入门

Mozilla 安全
Mozilla 安全博客
漏洞赏金计划
YouTube 上的 Mozilla 安全播放列表