CVE 争议

几年前，curl 项目签约并成为 CNA。这意味着我们是 CVE 标识符的主人并且可以分配我们自己的 CVE 标识符。对于我们境内的任何安全问题，由我们决定该问题是否应该获得 CVE。不再有伪造的 CVE。 57 个 CVE 这些年来，我们发布了 57 个独立的安全漏洞及其相关的 CVE 标识符。当您是 CNA 时，获取某个问题的 CVE 非常简单且快速。没有麻烦，没有摩擦，由于我们是一个小而精干的安全团队，所以它会像您所要求的那样顺利工作。只需一个 API 调用，我们就有了新号码。成为 CNA 的维护成本很低，因为我们实际上不需要做任何额外的事情。在成为 CNA 之前，我们已经建立了一套经过验证的接收、管理和评估漏洞报告的流程，因为我们是一个负责任且运行良好的开源项目。成为 CNA 使整个过程变得更加容易，因为我们现在根本不需要任何外人的参与。评估 对于每一份报告，我们都会努力首先评估并确定该问题实际上是漏洞还是安全问题。如果我们认为其中存在安全问题，我们会将其分为低、中、高或严重。由于我们不知道用户如何使用curl或libcurl，因此我们无法考虑这一点，而是从纯粹的curl角度观察并设置问题的严重性。这是我们如何看待问题的粗略指示，但当然，每个实际受到该问题影响的用户可能会有不同的评价。低于低 对于极少数问题，我们可以想象可能存在微小的风险，但由于实现这一目标的一系列极端要求和复杂的步骤，我们认为风险很小，以至于实际上没有用户可能达到它。在内部，我们倾向于将其称为严重级别低于“低”的问题。我们认为，通过不发布 CVE 可以更好地为人类服务。避免在看似不必要的情况下进行安全舞蹈。 CVE libcurl 的成本安装在全球大约 300 亿个实例中。如果我们想象这些安装中至少有相当一部分是由希望确保使用安全版本的人管理的，则意味着我们发布的每个 CVE 都会触发世界各地许多安全团队的活动，从而导致大量补丁和后续软件更新。因此，每个 CVE 都伴随着巨大的成本。这种成本不会落在我们身上，我们也没有真正看到或感觉到它，但我认为我们不应该忽视生态系统的成本。我们应该负责任地行事。当然，永远不要忽视实际问题，但也要确保我们不会为不会触发任何漏洞的理论问题敲响警钟。争议 自我们成为 CNA 以来，我们首次收到 CVE 争议，我们于 2026 年 2 月 10 日收到了两个月前提交给我们的报告。记者认为我们应该将他们报告的问题指定为 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 日修复了此问题，并针对此场景添加了单元测试，以确保问题不会再次出现。对于低于 HIGH 的所有安全问题，我们会尽快修复它们，这只是我们的正常程序。我们