LWN：内核CVE编号是如何分配的！

关注了就能看到更多这么棒的文章哦～

How kernel CVE numbers are assigned

June 19, 2024

This article was contributed by Lee Jones
Gemini-1.5-flash translation
https://lwn.net/Articles/978711/

距离 Greg Kroah-Hartman 和 MITRE 宣布 Linux 内核项目成为其自身的 CVE 编号机构 (CNA) (CVE Numbering Authority) 已经过去四个月了。从那时起，Linux CNA 团队就一直在建立工作流程和机制，以帮助管理与这一挑战相关的各种任务。然而，社区成员似乎对团队一直在使用的流程和规则缺乏了解。本文由 Linux 内核 CNA 团队成员撰写，其主要目的是阐明团队的工作方式以及内核 CVE 编号的分配方式。

早期的 CVE 公告引发了一些问题，包括 在邮件列表中 以及其他一些地方。Linux CNA 团队收到了坚定支持的信息，特别是来自那些致力于 Linux 安全的人。其他一些表达担忧的意见主要来自分发商和维护企业平台的团队，这些团队试图通过尽可能少的变更来保持稳定和安全。提出的一些较强有力的观点是，CVE 数量的增加将增加工作量，并压垮那些试图审查所有 CVE 的安全团队。其他人则认为，发行版和企业级别的 CVE 用户，特别是那些为这项服务付费的用户，应该一直在审查稳定版中提交的所有代码，以查找对相关安全漏洞的修复。一位独立的安全维护者对付费分发版没有审查除了那些被识别为 CVE 候选者的稳定修复之外的其他 fix 感到特别震惊，因为他们本来应该这样做。

无论贡献者站在哪一边，几乎所有人都同意：由于各种原因，旧的 CVE 流程运行得不好。LWN 在 这篇最近的文章 中列出了许多主要观点。另一个值得关注的要点是，许多下游维护者（包括我在内，尽管 Android 有来自长期支持稳定内核的定期合并的额外安全保障）对 cherry-picking 所有相关 CVE 并将其视为持续安全更新的良好做法感到满意。当然，这种做法会导致一种错误的安全感，因为它遗漏了数百个与安全相关的修复，最终会导致内核安全性降低。

新的流程更加全面，旨在识别每个修复潜在安全问题的提交。有些人提到他们认为这种策略有点过于热心，然而，自从我们在 2 月份开始这项工作以来，它只在 v6.7.1 和 v6.8.9 之间的 16,514 次提交中分配了 863 个 CVE 编号。这仅仅是 5% 的比例。

Kroah-Hartman 和其他人分享的历史想法以及对当前文献的误解加剧了负面意见。在关于 2019 年 内核食谱讨论 的一篇文章中，Kroah-Hartman 被转述为说：“下一个选项，‘烧毁它们’，可以通过为应用于内核的每个补丁请求 CVE 编号来实现。” 事实上，该计划从未打算制造大量的 CVE 编号来压倒当前系统，从而使其最终被放弃，而且这种情况也从未接近成为现实。Linux CNA 团队谨慎地将 CVE 分配降到最低，只为对安全构成潜在风险的漏洞分配编号。

不幸的是，文档 中的一些说法并不能很好地消除这些担忧。例如，这部分内容经常被引用：

因此，CVE 分配团队过于谨慎，正在为他们识别到的任何错误修复分配 CVE 编号。这解释了 Linux 内核团队发布的 CVE 数量似乎很大。

这部分内容经常被误解或被过分地理解。关于为“任何错误修复”分配 CVE 编号的部分应该扩展为“任何与内核安全态势相关的错误修复”。例如，修复损坏的 LED 驱动程序的修复永远不会被考虑来分配 CVE。也就是说，这样规定了问题的确切类型之后数量就会大大减少。最近有人尝试这样做，并提交给 security@kernel.org 进行预审查，但立即被该组拒绝。然而，我寻找的非详尽考虑清单包括缓冲区溢出、数据损坏、崩溃 (BUGs 、oops 和 panic，包括受 panic_on_warn 影响的那些)、使用后释放 (UAF)、锁死、双重释放、拒绝服务 (DoS)、数据泄露等。

一个不时出现的问题可以概括为：“为什么我们如此热衷于此，为什么我们不能只为严重的安全性修复创建 CVE？”；答案是质量评估是一项不可能的任务。由于内核是无限可配置和可适应的，因此无法知道它可以部署和使用的所有方式。评估潜在的漏洞并将通用的漏洞可达性、严重性和影响级别相关联是不可行的。在一个平台上无法利用的漏洞可能在另一个平台上很容易被利用。即使一个特定问题可以被证明是普遍来说都是低风险的，它仍然可能被用作更复杂、更链式攻击中的一个垫脚石。由于所有这些原因以及更多原因，我们发现最明智的方法是假设“安全漏洞就是漏洞”，并为任何可能与安全相关的任何问题分配编号。

Linux CNA 团队不会轻易进行 CVE 编号分配，这个过程也不是自动化的。在第一个完整版本 (6.7.y) 中，这个过程包括团队中的所有三名成员（Greg Kroah-Hartman、Sasha Levin 和我）手动审查每个打入稳定分支的补丁，并对每个补丁进行投票。如果一个提交获得了三个赞成票，就会分配一个 CVE 编号。获得两票的提交将接受第二次审查，然后进行讨论。

团队成员以各种方式来 review 这些改动。其中一人使用 Mutt 以与他们审查 mainline 补丁提交完全相同的方式进行审查，另一人正在训练一个机器学习 (ML) 模型来识别难以发现的问题，而我更喜欢把 Git 输出用管道传输给一个辅助工具，该工具突出显示了容易获得“Yes”投票的典型代码样例。“No”投票需要更多时间来审查。目前的想法是，通过使用不同的工具和方法，我们的正面结果将更加稳健；至少理论上是这样。

一旦 CVE 创建完成，它们就会提交到 linux-cve-announce 邮件列表，感兴趣的人们可以在闲暇时审查它们。SUSE 的工程师在这方面功不可没。他们在对那些以前的 CNA 以不可搜索的方式提到的重复 CVE，或者是不值得分配 CVE 最终分配 CVE 的过程中发挥了重要作用。他们的意见帮助塑造了团队现在进行分析的方式。任何人都可以自由地 review 甚至被鼓励来 review 我们的 linux-cve-announce 列表，并回复他们认为无效的 CVE。如果团队同意这个判定，则 CVE 分配将被立即拒绝。自从这项工作开始以来，已经发生了 65 起这样的情况。

希望这有助于澄清目前关于用于审查、识别和处理 CVE 候选人的方法的一些误解，并消除最近人们向我传达的一些担忧。具体来说，CVE 编号不是以自动方式分配的，它们只分配给可能合理地被认为具有安全隐患的漏洞。该团队对建设性反馈和改进的真正建议持开放态度；它致力于履行其责任，并在流程的所有阶段都谨慎行事并尽职尽责。如果您有任何问题或建议，您可以使用内核的 Documentation/process/cve.rst 文件中提供的联系方式。我们很乐意收到您的来信。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～