LWN：用 !CVE 作为CVE的补充！

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

Supplementing CVEs with !CVEs

By Jake Edge
December 5, 2023
ChatGPT translation
https://lwn.net/Articles/953738/

通用漏洞和利用（CVE, Common Vulnerabilities and Exploits）系统是跟踪各种安全漏洞的一个主要机制，使用普遍存在的 CVE 编号，哪怕是那些有花哨名称甚至网站的漏洞，也有 CVE 编号。然而，CVE 系统并非没有批评者，事实上，报告方和处理漏洞的责任方之间的激励一直存在错位，导致各种滥用。人们一直在努力打击其中一些滥用行为；一个新宣布的"!CVE"项目旨在跟踪那些"厂商未承认但仍然是严重安全问题"的漏洞。

"!CVE 团队"于 11 月 8 日在 oss-security 邮件列表上发布了这一公告；该项目刚刚在由Cyber Intelligence, S.L.（一家西班牙安全研究公司）的 Hector Marco 和 Samuel Arevalo在Black Hat Toronto上演示。鉴于 Cyber Intelligence是!CVE网站上唯一的合作伙伴，很难不得出结论 Marco 和 Arevalo 是!CVE 团队的一部分（或全部），尽管其成员名义上是匿名的。

新项目成立的原因非常简单：用来跟踪那些被相关 CVE 编号授权机构（CNA）拒绝分配 CVE 的漏洞。 CNA 被委托为特定产品或项目分配 CVE，而在许多情况下，就是厂商本身或者项目本身。相关公告中引用了CNA规则："CNA 可以自行决定某个问题是否是漏洞"。由于 CNA 通常和跟相关代码的 owner 有关，因此公告指出存在问题：

这构成了明显的利益冲突，因为是同一厂商决定某个问题是否是漏洞，从而决定是否为其产品分配 CVE。

该项目认为解决方案是由专家小组评估此类漏洞的报告；如果它们符合条件，将分配一个!CVE-yyyy-nnnn 标识符，并在 NotCVE 数据库中创建一个条目。正如人们可能预测到的那样，标识符中的感叹号并不受欢迎，Alexander "Solar Designer" Peslyak 在对公告的第一个回应中指出编号方案存在缺陷：

请使这些更加独特，以便搜索（例如在 Web 或邮件列表存档中）不会同时找到 CVE-2023-0001 和!CVE-2023-0001，因为它们可能完全不相关。实际上，专门搜索!CVE 可能会很困难，因为在索引内容时感叹号可能会被标记器删除。

他还指出，他在 2016 年就创建了一个CVE替代方案，称为OVE，尽管它从未真正起作用；"也许你的方案会成功。" David A. Wheeler建议使用"NotCVE"而不是"!CVE"，这也是团队最终决定采纳的方案。查找第一个警报可以使用任一种标识符，因为可能已存在对!CVE-2023-0001的引用。

在帖子中，Mike O'Connor提出了关于那些不是供应商的 CNA，指出 GitHub CNA 负责许多其托管的开源项目，但对于它们来说并非是“供应商”。他提出了一种情况，即 CNA 有正当理由拒绝 CVE 分配：

也许他们不想构建几十年前已弃用的代码来确定某个随机模糊机器人发现的缓冲区溢出的严重性。对于 Linux 内核来说，大多数安全修复都有 git 提交哈希，但没有 CVE，!CVE 如何产生作用？

!CVE 团队表示该项目将仅跟踪未分配 CVE 的漏洞—出于任何原因。它不仅仅是对已被拒绝 CVE 分配的漏洞，事情并不止于此：

!CVE 项目正在跟踪、识别和分享那些可能会被随机发布在博客、Twitter 等（在最好的情况下）或者丢失的安全问题。要获得 NotCVE 与某人是否难以获得其漏洞的 CVE 无关。要获得 NotCVE，该问题必须符合条件。

O'Connor 还建议与 CVE 项目合作，"解决你认为可能违反 CNA 规则的问题"，但!CVE 团队表示 MITRE（运行 CVE 项目的机构）并不是对此一无所知：

MITRE 或供应商对此并非不了解或不知情。在某些情况下，MITRE 赞成分配 CVE，但供应商反对。在这些情况下，MITRE 无能为力，根据经验我们可以告诉您，最终 CVE 将不会被分配出来。请注意，“安全问题”甚至不能被称为“漏洞”，因为根据 MITRE 规则，只有供应商有这个权限来确定。如果某事不是“漏洞”，就没有什么需要修补的，没有什么需要追踪的，等等。由于这些问题被忽视，它们应该更加谨慎地被看待，因为它们可能不会被修复。

乍一看，跟踪未跟踪的漏洞似乎是一个完全合理的想法—而且确实如此—但也存在一些风险。当前系统的最大问题来自于激励错位；研究人员出于自我认可的目的会推动分配 CVE，而公司和其他一些人有时希望放弃 CVE，以便 不 被认定为存在安全漏洞。与此同时，政府等机构有法律和规范要求在很短的时间内发布有关 fix，这给供应商和项目提供了另一个避免创建 CVE 的理由。

除此之外，如果项目没有创建自己的 CNA，那么项目将不得不处理虚假的CVE。NotCVE 的实用性将取决于“专家小组”在阻止虚假报告被添加进来这个方面的表现。如果 NotCVE 系统变得流行，它将为只关心个人成就感的研究人员提供另一个目标，因此该项目可能会被各种虚假报告淹没。

总之，CVE 系统混乱不堪—而且定期产生一些试图修复或替换CVE系统的方案。到目前为止，至少还没有一个方案取得了很大进展，!CVE 看起来可能也会是其中之一。但它试图解决的问题依然存在。因此，在未来的几年—甚至是几十年或更长时间内—我们可能会看到更多零星的、通常是不切实际的对抗 CVE 这个风车的尝试。

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

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

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