关注了就能看到更多这么棒的文章哦~
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 深度文章以及开源社区的各种新近言论~