6.0
关注
AI SCORE
技术实践2026-05-08 00:05
用 Claude 强化 Firefox 安全——AI 在浏览器防护中的应用
Hacker News · hacks.mozilla.org#Firefox#安全#Claude
Editor brief · 编辑速览
Mozilla 官方用 Claude Mythos Preview 提高 Firefox 安全防护，展示 AI 在系统安全工程中的实践案例。
两周前，我们宣布，在 Claude Mythos Preview 和其他 AI 模型的帮助下，我们发现并修复了 Firefox 中数量空前的潜在安全漏洞。在本文中，我们将更详细地介绍我们如何开展这项工作、发现了什么，以及其他项目应如何充分利用这些新兴能力，加固自身以抵御攻击。
就在几个月前，开源项目收到的 AI 生成安全漏洞报告，大多还只是无人想要的低质内容。处理那些看似合理、实则错误的报告，会给项目维护者带来不对称的成本：通过 prompt 让 LLM 在代码中找出一个“问题”既便宜又容易，但回应和处理它却缓慢而昂贵。
很难夸大这种局面在短短几个月内发生了多么巨大的变化。背后主要有两个因素。第一，模型的能力大幅提升。第二，我们显著改进了驾驭这些模型的技术——包括引导模型、扩大规模，以及将多个模型或步骤层层组合，从而生成大量有效信号并滤除噪声。
通常，在发布修复并公布安全公告后，我们仍会将详细的漏洞报告保密数月。这主要是一项预防措施，用来保护那些出于各种原因未能及时更新到最新版 Firefox 的用户。鉴于这一话题受到的关注非同寻常，而且整个软件生态迫切需要采取行动，我们经过权衡，决定公开近期已发布修复背后的一小部分报告样本。我们尽量从浏览器的不同子系统中选取样本，不过整个选择过程仍带有一定随意性。尽管如此，我们希望这些报告所展现出的深度和多样性，能够为我们对相关能力的判断提供佐证，也能让更多防御者认真考虑我们的呼吁：开始应用这些技术。
需要注意的是，其中一些漏洞属于 sandbox escape。要完整攻破 Firefox，还需要将它们与其他 exploit 组合成攻击链。这些报告假设：负责渲染网站内容的 sandboxed process 已经通过另一个独立漏洞被攻破，现在其中正在运行攻击者控制的机器码，试图进一步取得 privileged parent process 的控制权。在构造 sandbox escape 时，允许模型修改 Firefox 源代码，但修改后的代码必须仅限于在 sandboxed process 中运行[1]。众所周知，这类漏洞很难通过 fuzzing 找到。尽管我们在开发新技术、弥补这一缺口方面取得过一些进展，但 AI 分析能够对这一关键攻击面提供全面得多的覆盖。
与模型发现了什么同样有趣的，是它们没能发现什么——不是因为它们没有尝试，而是因为它们无法绕过 Firefox 的多层防御。例如，近几年我们收到过安全研究人员提交的几份巧妙报告，它们通过在 privileged parent process 中触发 prototype pollution，成功实现了 process sandbox escape。我们没有逐个修复这些问题，而是从架构层面作出改变，默认冻结这些 prototype。在审计 harness 的日志时，我们看到模型多次尝试沿着这条路径实现逃逸，但都被这一设计拦截了。亲眼看到过去的加固工作带来如此直接的回报，甚至比发现并修复更多漏洞更令人欣慰。
过去几年里，我们一直在内部尝试使用 LLM 进行代码审计。早期的尝试包括使用 GPT 4 或 Sonnet 3.5 等模型，对高风险代码进行静态分析以寻找漏洞。这些实验展现出了一些潜力，但由于误报率太高，无法实际扩大规模。
能够可靠检测安全问题的 agentic harness 出现后，局面彻底改变了。它们既能找到真实漏洞，也能排除无法复现的猜测。此类 harness 的关键能力在于：只要提供合适的接口和指令，它就能创建并运行可复现的 testcase，通过动态方式验证有关代码漏洞的假设。在修复 Anthropic 于 2 月发给我们的第一批问题后，我们基于现有的 fuzzing 基础设施构建了自己的 harness。
一开始，我们进行了小规模实验，通过 prompt 指示 harness 使用 Claude Opus 4.6 寻找 sandbox escape。即使使用这个模型，我们也发现了数量可观的未知漏洞，而发现这些漏洞需要对多进程浏览器引擎代码进行复杂推理。最初，我们在终端中监督整个过程，实时观察其运行，并调整 prompt 和逻辑。这套方案运行良好后，我们将任务并行分发到多个临时 VM。每个 VM 都负责在指定的目标文件中寻找漏洞，并将发现写回 bucket。
只有发现子系统还不够。为了扩大这项工作的规模，我们需要将它整合进完整的安全漏洞生命周期：决定寻找什么、去哪里寻找，以及如何处理产出结果。最后一部分包括与已知问题进行去重、跟踪漏洞、完成漏洞分诊，以及推动修复发布。模型是驱动 harness 的核心原语，但要让它真正大规模发挥作用，完整的流水线必不可少。
harness 或许可以跨项目复用，但这套流水线天然需要针对具体项目定制，以反映每个代码库各自的语义、工具和流程。搭建这套系统需要大量迭代，并与负责处理新提交漏洞的 Firefox 工程师保持紧密的反馈循环。
一旦端到端流水线就位，有新模型可用时，替换模型就非常简单。尽早构建这条流水线，不仅帮助我们借助公开可用的模型发现了许多严重漏洞，也让我们在获得评估 Claude Mythos Preview 的机会时能够立即进入状态。根据我们的经验，模型升级会提升整条流水线的有效性：系统会同时变得更擅长发现潜在漏洞、创建用于证明漏洞的 proof-of-concept testcase，以及清晰阐述漏洞的成因和影响。
除了在 Firefox 150 中修复 Claude Mythos Preview 发现的 271 个漏洞外，我们还在 149.0.2、150.0.1 和 150.0.2 中发布了更多此类修复。与此同时，我们仍在通过其他内部手段发现漏洞；与其他项目类似，过去几个月里，我们收到的外部报告数量也显著增加。
归根结底，要正确修复每一个漏洞，都需要投入细致的关注和精力。为了跟上这前所未有的漏洞数量，过去几个月里，我们付出了大量劳动，也经历了许多个漫长的工作日。团队挺身而出迎接挑战，我们对此感到无比自豪。超过 100 人为这项工作贡献了代码，共同发布了迄今为止最安全的 Firefox。除了编写和审查 patch，还有许多人在构建并扩展这套流水线、进行漏洞分诊、测试修复，以及管理每个漏洞的发布流程。
任何开发软件的人，现在都可以开始使用搭配现代模型的 harness 来寻找漏洞并加固代码。我们建议立即开始。你一定会发现漏洞，也能提前做好准备，在新模型一经推出时便充分利用它们。
你可以从非常简单的 prompt 开始，然后观察结果并持续迭代。我们最初使用的 prompt，与这里描述的并没有太大区别。通过不断迭代，我们构建了大量编排逻辑和工具，以优化并扩展流水线；但内部循环的本质始终没有改变：这部分代码里有一个漏洞，请找到它并构建一个 testcase。
我们还没有挖尽 Firefox 中所有潜藏的漏洞，但目前的发展趋势令我们相当满意。现在，我们的扫描主要集中于代码中的特定区域，例如文件和函数；我们根据人工判断与自动化信号的组合，指示系统在这些区域中寻找漏洞。在不久的将来，我们计划将这套分析集成到 continuous integration 系统中，在 patch 进入代码树时立即扫描。模型对于所提供 context 的形式非常灵活，因此我们预计，基于 patch 的扫描效果可以达到甚至超过基于文件的扫描。
当下的处境危机四伏，但也充满机遇。让我们携手保障互联网的安全。
在安全公告网页上，我们会把所有内部报告的漏洞归为“汇总型” CVE，每个 CVE 下包含多个漏洞。该网页由 foundation-security-advisories repo 中的 yaml 构建；这个 repo 是我们分配 CVE 的权威来源。有些浏览器根本不会为内部发现的问题创建 CVE 标识符，而我们选择提供这些信息，以尽可能保持透明。
Firefox 150 中有三个内部汇总项：CVE-2026-6784（154 个漏洞）、CVE-2026-6785（55 个漏洞）和 CVE-2026-6786（107 个漏洞）。
敏锐的读者会注意到，这些内部汇总项中的漏洞数量相加是 316，超过了我们宣布使用 Claude Mythos Preview 发现的 271 个漏洞。这是因为我们的安全团队每天都在通过多种方式攻击 Firefox、寻找新漏洞，包括：（a）fuzzing 系统；（b）人工检查；（c）这条使用多种模型的新 agentic 流水线。
我们在 4 月的各个版本中总共修复了 423 个安全漏洞。除了两周前宣布的 271 个漏洞，还有 41 个由外部报告的漏洞；剩余 111 个由内部发现，大致平均分为以下三类：
使用 Claude Mythos Preview 通过这条流水线发现、但在 Firefox 150 之外的其他版本中修复的漏洞
使用其他模型通过这条流水线发现的漏洞
使用 fuzzing 等其他技术发现的漏洞
另请注意，除这次最新工作外，我们还将 3 个 CVE 直接归功于 Anthropic，分别是 CVE-2026-6746、CVE-2026-6757 和 CVE-2026-6758。这些 CVE 修复的是几个月前由出色的 Anthropic Frontier Red team 发给我们的漏洞。按照正常流程，我们为每个漏洞分别分配了独立的 CVE。
补充一些背景信息：我们会为漏洞评定从 critical 到 low 的安全严重性等级，用于表示漏洞的紧急程度：
sec-critical 和 sec-high 用于可以通过正常用户行为触发的漏洞，例如浏览某个网页。在技术层面，我们并不区分二者，但 sec-critical 专门用于已经公开披露或已知在真实环境中遭到利用的问题。
sec-moderate 用于那些原本会被评为 sec-high、但需要受害者执行异常且复杂操作才能触发的漏洞。
sec-low 用于那些虽然令人困扰、但远不足以对用户造成伤害的漏洞，例如安全的崩溃。
在我们为 Firefox 150 宣布的 271 个漏洞中：180 个为 sec-high，80 个为 sec-moderate，11 个为 sec-low。
尽管我们最重视 critical/high 漏洞，但为了修复正确性问题，并将其作为 defense-in-depth 机制，我们也通常会优先处理 moderate 和 low 级别的安全漏洞。
在大多数情况下，单个 critical/high 漏洞实际上不足以攻破 Firefox。这是因为 Firefox 采用了 defense-in-depth 架构。例如，利用一个 JIT 漏洞，只能在经过 sandbox 隔离且限定于特定网站的进程中实现 remote code execution。现实世界中的攻击者通常需要将多个 exploit 串联起来，穿透一层或多层 sandbox 以提升权限，同时还要绕过 ASLR 等操作系统级缓解措施。
我们通常也不会专门构建 exploit，来确认某个漏洞能否被攻击者用于现实攻击。我们会根据可预测的崩溃症状，将漏洞归类为 sec-high，例如 AddressSanitizer 报告的 use-after-free 或 out-of-bounds 内存问题。我们的 threat model 假设，只要投入足够精力，任何此类漏洞都有可能被利用。这种做法降低了 exploitability 分析中出现假阴性的风险；更重要的是，它让我们能够把资源集中用于发现并修复更多漏洞。
[1] 我们的 bug bounty program 也有类似规则。↩
Firefox 杰出工程师
Brian Grinstead 的更多文章……
Christian 是 Mozilla 的 Firefox Tech Lead 和首席工程师。
Christian Holler 的更多文章……
Frederik Braun 负责管理 Firefox Application Security 团队。他身在柏林，致力于为 Web 和 Mozilla Firefox 构建安全保障。作为标准制定工作的贡献者，Frederik 还通过 Sanitizer API 和 Subresource Integrity 等规范，将安全性纳入默认机制，从而改进 Web 平台。工作之外，Frederik 喜欢阅读优秀的小说，也喜欢骑自行车长途穿越欧洲。
Frederik Braun 的更多文章……