安全漏洞审批流程

如何在 Firefox 中修复核心安全漏洞 - 开发人员指南

如果您参与安全补丁的审查、测试和落地，请遵循以下安全指南：修复安全漏洞。

目的：避免 0 天漏洞

人们会关注我们的代码提交。如果

  • 补丁是一个明显的安全修复（边界检查、kungFuDeathGrip 等）

  • 提交注释中说“安全修复”或包含触发词，如“可利用”、“易受攻击”、“溢出”、“注入”、“释放后使用”等

  • 代码中的注释提到了这些类型的事情或有人如何滥用漏洞

  • 提交包含测试用例，准确展示了如何触发漏洞

原则：假设最坏情况

  • 如果没有评级，我们假设它可能是严重的

  • 如果我们不知道回归范围，我们假设它需要移植到所有受支持的分支

安全漏洞流程（开发者视角）

提交/管理漏洞

  • 尽可能在提交时将安全漏洞标记为安全漏洞，而不是将其作为公开漏洞提交，然后再关闭。这并非总是可行，但尤其是在从崩溃统计信息中提交时，请注意这一点，这将很有帮助。

  • 使用“阻塞”、“依赖”、“回归”或“另请参阅”将安全漏洞链接到非安全漏洞是_可以_的。拥有 editbugs 权限的用户将能够看到引用，但不能查看受限制的漏洞或其摘要。没有权限的用户将无法看到链接。对于即使这样似乎也存在问题的严重漏洞，请考虑在安全漏洞的注释中提及该漏洞。我们可以在修复程序发布后随时填写链接。

开发补丁

  • 代码中的注释不应提及正在修复安全问题。不要比代码更改本身更详细地描述安全问题或指向安全问题。

  • 如果可能，请勿推送到 Try 服务器：这会将这些严重和高评级漏洞的安全性问题公开给公众查看。理想情况下，补丁的测试在最终签入 mozilla-central 之前在本地进行。

  • 如果必须推送到 Try 服务器，则**不要在补丁中包含漏洞编号**。理想情况下，不要在推送中包含测试，因为测试通常会说明安全问题的具体性质。

  • 如果必须推送到 Try 服务器，无论是否包含测试，请尝试混淆此补丁的用途。尝试将其与同一区域的其他非安全工作一起推送。

按照正常流程请求审查补丁。补丁经过审查后，您将根据需要请求安全审批。有关这些要点更多示例/详细信息，请参阅修复安全漏洞。

准备补丁以供落地

有关更多详细信息，请参阅修复安全漏洞。

关于请求安全审批

对于没有安全严重性评级的安全漏洞，请假设最坏的情况并遵循安全关键的规则。在安全审批过程中，我们会注意到它未被评级，并在过程中进行评级。

核心安全漏洞修复可以在没有明确批准的情况下由开发人员落地，如果

**A)** 漏洞具有安全低、安全中、安全其他或安全想要评级。
或者
**B)** 漏洞是 mozilla-central 上最近的回归。这意味着

  • 已识别出特定的回归提交

  • 开发人员可以（并且已经）将 ESR 和 Beta 的状态标志标记为“不受影响”

  • 我们尚未在除夜间构建之外的任何内容中发布此漏洞

如果满足上述条件，开发人员无需请求安全审批。

在所有其他情况下，开发人员应请求安全审批。当补丁准备就绪要落地时，请单击 Bugzilla 附件表中补丁的“详细信息”链接（在撰写本文时不要直接在 Phabricator 上），然后将安全审批标志设置为“？”。

如果开发人员不确定某个漏洞并且它已准备好补丁，只需请求安全审批并继续。不要想太多！

当安全审批设置为“？”时，会自动向 Bugzilla 添加提名注释。请求补丁的安全审批时，需要尽可能完整地填写其中的问题。

如下所示（由 Dan Veditz 提供）

[Security approval request comment]
How easily can the security issue be deduced from the patch?
Do comments in the patch, the check-in comment, or tests included in
the patch paint a bulls-eye on the security problem?
Which older supported branches are affected by this flaw?
If not all supported branches, which bug introduced the flaw?
Do you have backports for the affected branches? If not, how
different, hard to create, and risky will they be?
How likely is this patch to cause regressions; how much testing does
it need?

这类似于 ESR 批准提名表单，旨在帮助我们评估批准补丁以供签入的风险。

当漏洞被批准落地时，安全审批标志将被设置为“+”，并附有审批者落地的注释。此时，请根据提供的说明落地。

这将使我们能够控制何时可以落地安全漏洞，而不会过早地公开它们，并确保它们在各个分支上落地。

如果您有任何疑问或不确定本文档中的任何内容，请在 Slack 的 #security 频道或当前的安全审批者 Dan Veditz 和 Tom Ritter 处联系我们。

安全漏洞流程（安全审批者视角）

安全保证团队和发布管理将有自己的漏洞批准流程

  1. 安全保证团队每天都会检查安全审批“？”漏洞，并批准中央的低风险修复（如果在周期早期）。开发人员也可以在 Slack 的 #security 中 ping 安全保证团队（特别是 Tom Ritter 和 Dan Veditz）。

    1. 如果漏洞缺少安全评级，则应分配一个评级 - 可能与（安全保证团队的其他成员）协调。

  2. 安全团队将所有受影响版本的跟踪标志标记为“？”以供中央使用。（这允许发布管理像往常一样决定是否提升到分支。）

  3. 每周的安全/发布管理分类会议将审查安全审批“+”和“？”漏洞（其中 Beta 和 ESR 受影响）、风险更高的“？”漏洞（安全高和安全关键）或周期结束附近的“？”漏洞。

安全审批选项包括以下逻辑组合

  • 将测试和代码中的注释分离到一个后续提交中，我们稍后会提交。

  • 删除提交消息并将其放在漏洞或后续提交的注释中。

  • 请将其与另一个提交捆绑在一起落地。

  • 今天落地。

  • 今天落地，稍后落地测试。

  • 在发布日期附近落地。

  • 在 Nightly 中落地以评估稳定性。

  • 今天落地并请求提升到所有分支。

  • 请求提升到所有分支，我们会尽快落地。

  • 化学泄漏时间

选择其中哪一个的决策过程是根据多个方面的感知风险

  • 易于利用

  • 逆向工程风险

  • 稳定性风险

最常见的选择是：稳定性风险不大，没有立即的逆向工程风险，利用难度中等至高：“随时落地”。