
Chainguard 启动 Project Theseus,首个组件 challoc 已开源
来源标题:Project Theseus, Starting with Challoc
Chainguard 宣布启动 Project Theseus,计划以公开方式逐个重建开源核心组件,以消除整类漏洞。首个组件 challoc 是用 Rust 编写的内存分配器,已在 GitHub 上公开。该项目旨在改变依赖人工修补漏洞的现状,从源头减少同类缺陷反复出现。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
所有文章2026年11月13日 隆重推出 Project Theseus,从 challoc 开始 John Slack John Slack 高级产品经理 + 另外 2 人 今天,我们宣布 Chainguard 的 Project Theseus,这项使命旨在重建开源的核心组件,并消除整类 bug。我们正以公开的方式,一个组件一个组件地推进。第一个组件 challoc 是一个用 Rust 编写的内存分配器,今天已在 GitHub 上公开。
全世界所依赖的开源软件,是在一个不同的时代、针对一种不同的威胁态势构建起来的。它的作者们使用的是当时手头可用的工具。C 语言把内存管理交到了程序员手中,每个项目都各自包含针对诸如转义 shell 命令或验证文件路径之类的检查。这些手写的检查每一个都依赖于程序员把一切都做对,而数十年的细致工作也未能阻止同类 bug 年复一年地出现。
我们知道不能永远只靠打补丁,必须想办法让这台跑步机慢下来。Chainguard 的计划是现在就着手,通过重建开源栈本身的一部分,以消除整类漏洞的方式来做。我们相信这在今天是可以实现的,而且结果可以易于迁移、更快,甚至更有趣。challoc 展示了这一切。
发现 bug 的速度已经远远快于修复 bug 的速度。通过 Project Glasswing,截至 11 月 2 日,Anthropic 已在 680 个开源项目中披露了 5,087 个漏洞。据 Anthropic 所知,其中只有 629 个已被修补。这并不是维护者的失职。AI 全天候地发现 bug,而每一个修复仍然必须由上游编写、审查并发布。
在上游发布修复只是开始。操作系统组件的每一个新版本都必须被某个发行版采纳、构建、发布,然后由用户部署。随着从披露到被利用的时间不断缩短,上述每一步都是攻击者的窗口期。这就是安全所奔跑的那台跑步机,而且它还在不断加速:Chainguard 如今每天发布的修复数量是一年前的七倍。
如果业界想要放慢这一节奏,就必须预防 bug,而不仅仅是打补丁。在广泛使用的正则表达式库 PCRE2 中,其 68 个 CVE 里有 53 个来自同样的几类错误,而现代语言和工具可以排除这类错误。正如我们在《Rebuild the planet》中所说:“你无法靠打补丁摆脱这一困境。”
这就是我们启动 Project Theseus 的原因:重写核心组件,使整类 bug 在其中不可能发生,从而需要修补的 bug 更少。
忒修斯之船是一个古老的思维实验:如果你一块一块地更换一艘船的木板,它还是同一艘船吗?Project Theseus 对开源栈做了类似的事情。它旨在替换那些同类 bug 不断出现的组件,一次一个。
这是一个实验,也是一组公开的代码仓库。每一个仓库都包含一个 Guarded Component,即某个核心开源组件的替代品,其构建方式使整类 bug 不可能发生。有些是我们用 AI agent 构建的重写版本,另一些则是我们采纳并加固的现有重写版本。两者都遵循同样的标准: 由我们所交付的内容塑造。每一个都针对它所替代的组件进行模糊测试。Chainguard 拥有超过 3,000 个生产镜像的目录,以及其背后数以万计的软件包,它们塑造了设计,并充当测试平台。 公开的证据。每个组件的源代码从我们宣布之日起就在 GitHub 上公开,同时还会在其就绪时公布一致性结果和性能对比,以及最关键部分的正式证明。 我们从内存安全、从内存分配器开始 Project Theseus,因为它几乎位于容器中运行的一切之下。challoc 是一个用 Rust 编写的分配器,旨在替代 glibc malloc、jemalloc、tcmalloc 和 mimalloc。它导出了标准 C 函数以及 jemalloc 的扩展 API,因此为 jemalloc 构建的程序无需改动即可在其上运行。 Project Theseus 的大部分都依赖同一种策略:以安全的 Rust 为核心,外面是一层经过审查的 unsafe 外壳。将此应用于分配器,就把这一策略推到了极限,因为它充当着其他一切所依赖的基础 unsafe 层。它的职责是把原始地址转换为供 C 程序使用的内存,而没有任何编译器能检查这一点。因此 challoc 对其 unsafe 代码的要求高于代码审查,其中大部分都经过了证明。这赋予了 challoc 两种安全性: 分配器自身的代码经过证明。Verus 是一个针对 Rust 的正式验证器,它依据书面契约证明了 challoc 86% 的函数和 94% 的代码行,而模型检查器则覆盖了边缘处的系统调用和汇编。这些证明包括:已分配的块永远不会与分配器元数据共享任何一个字节,以及过去 glibc、jemalloc 和 tcmalloc CVE 背后的尺寸溢出 bug 无法在主要入口点上发生。每一个剩余的假设都列在仓库中。 程序中的堆 bug 要难利用得多。challoc 无法让 C 程序变得内存安全,但它拿走了攻击者赖以构建的基础。它不把任何状态保存在你的数据之中或旁边,因此溢出或通过失效指针的写入都无法操纵分配器。尺寸类别位于独立的、随机化的地址范围中,彼此之间有保护区域。challoc 会检查无效释放和双重释放,一旦发现就中止程序,而一个可选启用的设置会让每一项检查都立即执行。 在《Rebuild the planet》中,我们运行了 Chainguard Harness——我们为 Project Glasswing 工作构建的 bug 发现工具——对每个发行版都会提供的五个软件包进行了扫描。它发现了 312 个不同的 bug,其中许多是内存安全 bug。在底下有 challoc 的情况下,其中近三分之一会安全地失败,而不是把控制权交给攻击者。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。