Mythos 发现 curl 漏洞

# Mythos 发现了一个 curl 漏洞 来源：https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/ 是的，是单数*一个*。 2026 年 4 月，Anthropic 引起了大量媒体关注，因为他们得出结论，其新 AI 模型*Mythos*在查找源代码中的安全漏洞方面*“危险地出色”*。显然，Mythos 在这方面表现得太好了，以至于 Anthropic 决定暂时不向公众发布该模型，而是将其逐步提供给少数精选公司，让一些优秀的公司（？）能够抢先一步修复最紧迫的问题，然后再让普通大众使用它。 整个世界似乎都失去了理智。这是我们已知世界的末日吗？这肯定是一个极其成功的营销噱头。 ## 我的（非）访问权限 *Glasswing 项目 (https://www.anthropic.com/glasswing)*协议的一部分是，Anthropic 还通过 Linux Foundation (https://www.linuxfoundation.org/) 向“开源项目”提供其最新 AI 模型的访问权限。Linux Foundation 让他们的项目 Alpha Omega (https://openssf.org/community/alpha-omega/) 处理这部分工作，我收到了他们的代表联系。作为 curl (https://curl.se/) 的主要开发者，我被提供了访问这个神奇模型的权限，我欣然接受了这个提议。当然，我想看看它能在 curl 中找到什么。 我签署了获取访问权限的合同，但随后什么也没发生。几周过去了，我被告知某处出了点问题，访问权限被推迟了。 最终，我得到的提议是：另一位拥有该模型访问权限的人可以使用 Mythos 对 curl 运行扫描和分析，并将报告发送给我。对我来说，这种区别并不重要。反正我没有太多时间去探索各种提示并进行深入挖掘。不管是谁做的，让工具生成第一次正式的扫描和分析都会很棒。我愉快地接受了这个提议。 （我故意省略了参与完成 curl 分析的个人的身份，因为这不是这篇博客文章的重点。） ## curl 的 AI 扫描 在这份最初的 Mythos 报告之前，我们已经用几种不同且非常强大的 AI 驱动工具扫描了 curl（我的意思是*除了*经常运行许多“普通”静态代码分析器、使用最挑剔的编译器选项并进行多年的模糊测试之外）。主要使用 AISLE (https://aisle.com/)、Zeropath (https://zeropath.com/) 和 OpenAI 的 Codex Security (https://developers.openai.com/codex/security) 来用 AI 审查代码。这些工具及其分析在最近的 8 到 10 个月内触发了约*两三百个*漏洞修复，并合并到了 curl 中。这些 AI 工具报告的一系列发现被确认为漏洞，并已作为 CVE 发布。大概有十几个或更多。 如今，我们还使用 GitHub 的 Copilot (https://github.com/features/copilot) 和 Augment code (https://www.augmentcode.com/) 等工具来审查拉取请求（PR），它们的意见和抱怨有助于我们合并更好的代码并避免引入新漏洞。我的意思是，我们当然还是会引入漏洞，但 PR 审查机器人经常指出我们修复的问题：如果没有它们，我们的合并质量会更差。AI 审查是*补充*人工审查的。它们帮助我们，而不是取代我们。 我们还看到*大量高质量的安全报告涌入 (https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/)*：安全研究人员现在广泛而有效地使用 AI。 安全是我们 curl 项目的*首要**任务*。我们遵循每一项指南，并正确地执行软件工程，以减少代码中的缺陷数量。扫描缺陷只是保持这艘船安全的许多步骤之一。你需要费力地搜索才能找到另一个在软件安全方面做得和 curl 一样多甚至更多的软件项目。 ## 2026 年 5 月 6 日 我们怀着极大的期待收到了第一份使用 Mythos 生成的源代码分析报告。这是我们再次发现需要改进的领域和需要修复的漏洞的机会。为了让 curl 变得更好。 这次初始扫描是在 curl 的 git 仓库及其主分支的*某个最近的提交 (https://github.com/curl/curl/tree/455bebc2c76223a1be26042f6d2393715c0df0cd)*上进行的。它统计了 src/ 和 lib/ 子目录中分析的 17.8 万行代码。 分析详细介绍了它所执行的几种不同的搜索方法，以及它如何专注于尝试查找哪些缺陷。报告顶部的一条有趣的注释说： > curl 是现存中经过最多模糊测试和审计的 C 代码库之一（OSS-Fuzz、Coverity、CodeQL、多次付费审计）。在热点路径（HTTP/1、TLS、URL 解析核心）中发现任何问题都是不太可能的。 ……并且它正确地发现在这些区域没有问题。 关于 Mythos 扫描 curl 的人们期望的 Mastodon 上的完全不科学的投票 ## curl 的规模 当我们排除空白行时，curl 目前有 176,000 行 C 代码。源代码由 660,000 个单词组成，比整本英文版《战争与和平》小说多出 12% 的单词。 平均而言，curl 的每一行生产源代码都被编写（然后重写）了 4.14 次。我们对此进行了打磨。 目前，git master 中仍然存在的生产代码由 573 个独立个人编写。随着时间的推移，总共有 1,465 个人的提议更改已合并到 curl 的 git 仓库中。 到目前为止，我们为 curl 发布了 188 个 CVE (https://curl.se/docs/security.html)。 curl 安装在*超过两百亿个实例*中。它在*超过 110 种操作系统*和*28 种 CPU 架构*上运行。它在地球上的每部智能手机、平板电脑、汽车、电视、游戏机和服务器上都运行。 ## 五个发现变为一个 报告总结称，它发现了**五个**“已确认的安全漏洞”。我认为当 AI 自信地自己说出*“已确认”*这个词时，使用这个术语有点令人 amusement。是的，AI 认为它们是已确认的，但 curl 安全团队对此有不同的看法。 考虑到我们预期会有一份详尽的清单，五个问题感觉微不足道。一旦我和 curl 安全团队的同事们花几个小时仔细研究这份简短的清单并深入细节，我们就将清单缩减，最终只剩下*一个*已确认的漏洞。其他四个是三个误报（它们指出了在 API 文档中有记录的不足），第四个我们认为是“只是一个漏洞”。 这个单一的已确认漏洞最终将成为一个*严重性低*的 CVE，计划与我们即将发布的下一个 curl 版本 8.21.0 同步发布，该版本将于 6 月底发布。这个缺陷不会让人窒息。当然，在那个时候之前，该漏洞的所有细节都不会公开，所以你需要等待详细信息。 Mythos 关于 curl 的报告还包含了一些被它判定为不是漏洞的已发现漏洞，就像任何新的代码分析器在数十万行代码上运行时所做的事情一样。报告中的所有漏洞都在调查中，我们正在逐一修复我们同意的漏洞。 总而言之，大约二十个漏洞被非常清晰地描述和解释。几乎没有误报，所以我推测它们对确定性的门槛相当高。 得益于这份报告，curl 肯定会变得更好，但按发现的问题数量计算，我们之前使用的所有 AI 工具都导致了更多的漏洞修复量。这当然是理所当然的，因为我们最初运行的工具有更多且更容易发现的漏洞。随着我们在途中修复了问题，发现新问题变得越来越难。此外，一个漏洞可能很小或很大，所以仅比较数字并不总是公平的。 ## 并不特别“危险” 然而，我的个人结论不能得出其他任何结论，即到目前为止围绕该模型的大大炒作主要是营销。我没有证据表明这种设置在以比其他工具在 Mythos 之前所做到的更高或更先进的程度上发现问题。也许这个模型稍微好一点，但即使如此，它也没有好到足以在代码分析方面造成显著影响。 这只是*一个*源代码仓库，也许它在其他方面更好。我只能评论和说明它在这里发现了什么。 ## 仍然非常好 但请允许我强调并重申我之前说过的话：AI 驱动的代码分析器在查找源代码中的安全缺陷和错误方面比过去任何传统代码分析器都*显著*更好。现在所有现代 AI 模型在这方面都很好。任何有时间且有一定实验精神的人现在都可以发现安全问题。*高质量的混乱 (https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/)*是真实的。 任何未使用 AI 驱动工具扫描其源代码的项目，很可能会用新一代工具发现大量缺陷、漏洞和可能的漏洞。Mythos 会，许多其他工具也会。 在你的项目中不使用 AI 代码分析器意味着你让对手和攻击者有时间发现并利用你未发现的漏洞。 ## AI 分析器的不同之处 - 它们可以发现当注释对代码说了什么，然后得出结论代码未按注释所说工作时。 - 它可以检查我们无法为其运行分析器的平台和配置代码。 - 它“知道”第三方库及其 API 的细节，因此它可以检测滥用或错误的假设。 - 它“知道” curl 实现的协议的细节，并且可以质疑代码中似乎违反或矛盾协议规范细节的部分。 - 它们通常擅长总结并解释缺陷，这在旧式分析器中是相当繁琐和困难的。 - 它们通常可以生成并提供其发现问题的补丁（即使补丁通常不是 100% 的修复）。 ## 来自报告的更多细节 **未发现零内存安全漏洞。** 方法论备注：此审查是使用 LLM 子代理进行并行文件读取的手工驱动分析，每个候选发现都在主要会话中通过直接源代码检查重新验证后才记录。CVE 到变种狩猎的映射是从 curl 自己的 vuln.json 构建的。没有使用自动化的 SAST 工具。 这一结果与 curl 作为最经过大量模糊测试和审计的 C 代码库之一的地位一致。防御基础设施（无处不在的 capped dynbufs，每次数字解析时带有显式最大值的 `curlx_str_number`，`curlx_memdup0` 溢出保护，CURL_PRINTF 格式字符串强制执行，每个协议的响应大小上限，pingpong 64KB 行上限）系统地关闭了在这个规模的代码库中通常会导致问题的漏洞类别。 覆盖率现在包括：所有次要协议、所有文件解析器、所有 TLS 后端的验证路径、http/1/2/3、ftp 全深度、mprintf、x509asn1、doh、所有身份验证机制、内容编码、连接重用、会话缓存、CLI 工具、特定平台代码以及 CI/构建供应链。 ## AI 发现现有类型的错误 应该注意的是，AI 工具发现的是我们已经知道的常见和既定类型的错误。它只是发现了它们的新实例。 到目前为止，我们还没有看到任何 AI 报告以某种新颖类型或完全新奇的方式发现的漏洞。它们并不以这种方式重新发明该领域，但它们确实比以前的任何工具都发现了更多的问题。 ## 还有更多要发现 这些绝对不是最后要发现或报告的漏洞。就在我为这篇博客文章撰写草稿时，我们收到了安全研究人员关于疑似问题的更多报告。AI 工具将进一步改进，研究人员可以找到新的和不同的方式来提示现有的 AI，使它们发现更多问题。 我们还没有到达尽头。 我希望我们可以继续用 Mythos 和其他 AI 对 curl 进行扫描，一遍又一遍，直到它们真正停止发现新问题。 ## 致谢 感谢 Anthropic 和 Alpha Omega 提供模型、工具并为我们进行扫描。也感谢为我们进行扫描的个人。非常感激！ 顶部图片由 Jin Kim (https://pixabay.com/users/jinwon198308-7490911/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3038833) 来自 Pixabay (https://pixabay.com//?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3038833) 感谢乘坐 curl。它永远不会乏味。