curl：一个 CVE 争议

# 一次 CVE 争议 来源：https://daniel.haxx.se/blog/2026/06/24/a-cve-dispute/ 几年前，curl 项目注册并成为了一个 CNA（CVE 编号机构）(https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/)。这意味着我们是自己 CVE 标识符的主人，可以自行分配。对于我们领域内的任何安全问题，是否分配 CVE 由我们决定。不再有虚假 CVE 了 (https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/)。 ## 57 个 CVE 这些年来，我们已经发布了*五十七个*独立的安全漏洞 (https://curl.se/docs/security.html)及其关联的 CVE 标识符。当你是一个 CNA 时，为问题获得 CVE 标识符非常容易且快速。没有麻烦，没有摩擦，而且由于我们是一个小而精干的安全团队，整个过程如你所期望的那样顺畅。只需一次 API 调用，我们就得到了一个新的编号。 成为 CNA 的维护成本很低，因为我们实际上不需要做任何额外的事情。在我们成为 CNA 之前，我们已经建立并验证了接收、管理和评估漏洞报告的流程 (https://curl.se/dev/vuln-disclosure.html)，因为我们是一个负责任且运行良好的开源项目。成为 CNA 只是让这个过程更容易了，因为我们现在根本不需要涉及任何外部人员。 ## 评估 对于每一份报告，我们都努力首先评估并确定该问题是否真的是一个漏洞或安全问题。 如果我们认为其中存在安全问题，那么我们会将其评级为低、中、高或严重。由于我们不知道用户如何使用 curl 或 libcurl，我们无法将这点纳入考虑，而是从纯粹的 curl 视角出发观察并设定问题的严重性。 这是我们看待该问题的大致指标，但当然，每个实际受到影响的用户可能会给出不同的评级。 ## 低于低级 对于极少数问题，我们能*想象*可能存在极小的风险，但由于需要满足一系列极端要求和复杂的步骤才能达到，我们认为风险如此之小，以至于实际上*不可能*有用户会遇到。在内部，我们倾向于称这种问题的严重性级别低于“低级”。我们认为，为这些问题发布 CVE 不符合人类的最佳利益，旨在避免在看似不必要的时候引发安全警报。 ## CVE 的成本 libcurl 在全球大约*三百亿个实例*中安装运行。如果我们假设其中相当大一部分的安装是由希望确保使用安全版本的人员管理的，那么我们发布的每个 CVE 都会触发全球众多安全团队的行动，导致大量的补丁和随后的软件更新。 因此，每个 CVE 都附带着巨大的成本。这个成本并不落在我们头上，我们实际上也看不到或感受不到，但我认为我们不应该忽视生态系统为此付出的代价。我们应该负责任地行事。当然，绝不忽略真正的问题，同时也要确保我们不会为理论上不会引发漏洞的问题拉响警报。 ## 争议 自我们成为 CNA 以来的第一次 CVE 争议于 2026 年 2 月 10 日到达我们手中，涉及一份两个月前提交的报告。报告者认为我们应该为他们报告的问题 (https://hackerone.com/reports/3455037)分配 CVE，但我们认为不应该。现在他们试图通过将情况升级到 MITRE 来强制要求分配 CVE。 是的，你会想知道*为什么*拥有这个 CVE 如此重要，但我现在会避免猜测。 我回复了 MITRE，解释我们考虑并讨论过该问题，并且我们仍然对之前的决定感到满意。我向他们链接了原始报告和讨论记录以供查看。 ## 主机名带有前导点 该问题相当技术性（当然），它基于 curl 用于检查所用主机名是否与证书中提供的通配符匹配的函数中的一个错误。 首先：用户必须在 URL 中使用一个带*前导点*的主机名，例如 `https://\.example\.com/`。 这种名称在 DNS 中无法使用（那里是非法名称），但你可以在 `/etc/hosts` 文件或类似文件中为其提供 IP 地址，不过这个前提条件已经使得这个问题非常小众了。 用户为什么会这样做呢？嗯，如果应用程序允许重定向，*可能*会从恶意服务器重定向到这样的主机名，但要获得该主机的地址仍然是一个挑战，并且通常需要本地攻击者在场。 其次：如果 curl 能为这个非法的 DNS 主机名找到一个地址，那么 curl 连接到的站点也需要拥有针对名称 `*\.example\.com` 的通配符证书，其中通配符的尾部需要与 URL 中的名称匹配。 如果 curl 是构建为使用 OpenSSL 变体或 Schannel 进行 TLS（请记住 curl 支持许多不同的 TLS 后端），它随后会调用 `Curl_cert_hostcheck()` 函数来检查通配符是否覆盖了所使用的主机名。 **此函数存在一个错误**。上述组合因此会错误地返回 TRUE（匹配）。而实际上，根据规范，这并不匹配。 我们在 2025 年 12 月 8 日 (https://github.com/curl/curl/commit/2535c4298fede065c80b9255328c18b68d739522)修复了此问题，并且为这个特定场景添加了单元测试以确保问题不会重现。对于所有严重性低于高的安全问题，我们都会尽快修复，这是我们的标准流程。然后我们继续讨论这是否值得分配一个 CVE。 ## 低于低级 除非是在内部受控环境中使用 DNS 以外的解析方式，否则使用点开头的名称应该是*极其罕见*的。 无法诱骗应用程序使用带前导点的任意名称，因为解析会失败。 这个明确设置的、奇怪的带前导点的名称，需要连接到一个为相同名称设置了通配符的主机，并且攻击者设法运行这个冒牌主机，然后就能向应用程序提供恶意数据，因为 curl 由于通配符不匹配而未能正确拒绝连接。 这是一系列极不可能发生的条件，全部满足才能成为一个漏洞。一个低于低级的情况；太不可能了；不分配 CVE。 ## 五月份再次 5 月 28 日，我们*再次*被 MITRE 联系，*就同一案例*，再次要求我们提供不为该问题分配 CVE 的理由。我们用几乎与之前相同的措辞再次回复，并再次链接到同一个 Hackerone 问题和讨论串。这些实际上都是公开信息。 ## 六月份再次 6 月 15 日，我们*再次*被 MITRE 联系，要求提供不为该问题分配 CVE 的决定背后的理由。 我们再次用类似的措辞回复。再次链接到同一个问题。 这看起来真是个*很棒*的系统。 ## 最终裁定 6 月 24 日，我们终于收到了最终裁定。该问题不被视为安全漏洞。 ``` 你好，宇浩， 感谢你参与关于 curl 直到 8.17.0 版本中报告问题的 CVE 争议流程。 MITRE TL-Root 已完成对所有相关方提供信息的审查，包括你提交的材料以及负责的 CNA 的回应。基于本次审查，MITRE TL-Root 确定将不会为报告的问题分配 CVE ID。 CNA 裁定（摘要）： “这是一个错误，现已在主分支中修复。由于它需要本地攻击者拥有特权才能实现，因此不被视为安全漏洞。” 在评估了现有证据和 CNA 的评估后，MITRE TL-Root 同意此裁定，并认为此事已解决。作为本次争议流程的裁决机构，MITRE TL-Root 的决定代表本案的最终裁定。 我们感谢你对 CVE 计划的参与，以及你在负责任地报告和协调安全问题方面所做的努力。 此致， MITRE TL-Root ```