Claude Mythos PreviewでFirefoxを強化した舞台裏
(hacks.mozilla.org)- Mozillaは、モデル性能の向上と**ハーネス（harness）**の改善により、AI生成のセキュリティレポートのシグナルを高めてノイズを減らし、Firefoxで実際のセキュリティバグを大規模に見つけるパイプラインを構築した
- Firefox 150 releaseでは、Claude Mythos Previewが特定した271件のバグが修正され、149.0.2、150.0.1、150.0.2にも関連修正が含まれている
- 公開された代表的なバグには、JITのWebAssembly GC構造体初期化削除による偽オブジェクトプリミティブ、IPC競合状態による親プロセスUAF、NaN逆シリアライズ問題、XSLTの20年来のrehashバグ、
rowspan=0を利用した16ビットレイアウトbitfield overflowなどが含まれる - 公開されたバグのかなりの部分はサンドボックス脱出であり、侵害されたコンテンツプロセスが権限のある親プロセスへ権限昇格する状況を前提とするため、ファジングだけでは見つけにくい攻撃面をAI分析がより包括的に扱った
- Mozillaは既存のファジング基盤の上にagenticハーネスを載せ、再現できない推測を捨ててテストケースで仮説を検証し、今後はパッチがtreeに入る際にスキャンするよう継続的インテグレーションへ統合する計画だ
AIモデルで明らかになったFirefoxセキュリティバグの変化
- 数か月前までは、オープンソースプロジェクトに届くAI生成のセキュリティバグ報告はもっともらしく見えても誤っていることが多く、メンテナーに非対称なコストを生んでいた
- Firefoxでは短期間で状況が大きく変わり、モデル性能の向上と、モデルを**ハーネス（harness）**で制御・拡張・結合してシグナルを増やしノイズをふるい落とす手法の改善が主因だった
- Mozillaは通常、セキュリティ勧告と修正配布の後も詳細なバグ報告を数か月非公開に保つが、今回はエコシステム全体の緊急性と関心を踏まえて一部の報告を公開することにした
- 公開された報告はブラウザの複数のサブシステムからまんべんなく選ばれており、選定にはある程度の任意性があるものの、その深さと多様性は防御側がこの手法を採用すべき必要性を示している
公開された代表的なバグ
- 2024918
- 誤った同値性検査のため、JITが生きているWebAssembly GC構造体の初期化を最適化で削除し、内外の研究者による広範なファジングを経たコードにおいて、潜在的な任意読み書きにつながる偽オブジェクトプリミティブを作り出せた
- 2024437
<legend>要素に関する15年来のバグで、再帰スタック深度制限、expando属性、cycle collectionなど、ブラウザの離れた領域にあるエッジケースを巧妙に組み合わせて引き起こされた
- 2021894
- IPC競合状態を安定して悪用することで、侵害されたコンテンツプロセスが親プロセスのIndexedDB参照カウントを操作し、UAFと潜在的なサンドボックス脱出を引き起こせた
- 2022034
- 生のNaNがIPC境界を越える際にタグ付きJSオブジェクトポインタのように見える可能性があり、doubleの逆シリアライズが親プロセスでの偽オブジェクトプリミティブとサンドボックス脱出につながり得た
- 2024653
- ネストしたイベントループ、
pagehideリスナー、ガベージコレクションを組み合わせた複雑なテストケースにより、<object>要素の属性setterでUAFを引き起こした
- ネストしたイベントループ、
- 2022733
- WebTransportに数千個の証明書ハッシュを押し込み、参照カウントの多いコピー処理ループの競合状態を拡大し、侵害されたコンテンツプロセスからIPC経由で親プロセスUAFを引き起こした
- 2023958
- glibcのDNS関数呼び出しを横取りして悪意あるDNSサーバーをシミュレートし、UDPからTCPへ切り替わるfallbackのエッジケースを再現して、HTTPS RRおよびECH解析中のバッファ過剰読み取りと親プロセスのスタックメモリ漏えいを引き起こした
- 2025977
- 再入可能な
key()呼び出しがハッシュテーブルのrehashを起こしてbacking storeを解放する一方で、生のエントリポインタが使われ続ける20年来のXSLTバグであり、修正された複数のsec-high XSLT問題の1つだった
- 再入可能な
- 2027298
- カラーピッカーにパッチを当てて自動化しにくいユーザー選択をシミュレートしたうえで、同期入力イベントでネストしたイベントループを回し、actor teardownに再入してcallbackが解放中に解放されるようにし、コンテンツプロセスUAFを引き起こした
- 2023817
- 侵害されたコンテンツプロセスが任意の壁紙画像を親プロセスでデコードさせることができ、仮想的な画像デコーダ脆弱性と組み合わせるとサンドボックス脱出につながり得た
- 親プロセスで入力の信頼水準を判断する、自動化しにくい推論が必要だった
- 2029813
- Firefox 95の細粒度サンドボックス技術であるRLBoxにおいて、信頼できない側から信頼側へ値をコピーする検証ロジックの隙を利用してサンドボックスを回避した
- 2026305
- HTMLテーブルの特殊な
rowspan=0の意味を利用する非常に小さなテストケースで、>65535行を追加してclampingを回避し、16ビットのレイアウトbitfieldをoverflowさせたもので、何年もの間ファザーに見つからなかった
- HTMLテーブルの特殊な
サンドボックス脱出と防御レイヤー
- 公開されたバグのかなりの部分はサンドボックス脱出であり、Firefox全体のチェーン侵害に至るには他のエクスプロイトと組み合わせる必要がある
- こうした報告は、サイトコンテンツをレンダリングするサンドボックス化プロセスが別のバグですでに侵害されており、攻撃者が制御する機械語コードが権限のある親プロセスへ権限昇格しようとする状況を前提としている
- サンドボックス脱出を作る際、モデルは修正したコードがサンドボックスプロセス内でのみ実行される限り、Firefoxソースコードをパッチできる
- この種のバグはファジングで見つけにくく、Mozillaはスナップショットを用いたIPCファジングのような手法を開発してきたが、AI分析はこの重要な攻撃面をはるかに包括的に扱えた
- モデルが見つけられなかった部分も重要だった
- ここ数年、セキュリティ研究者は、権限のある親プロセスでprototype pollutionを引き起こしてプロセスサンドボックスを脱出する報告を複数送ってきた
- Mozillaは問題を1件ずつ修正する代わりに、既定でprototypeをfreezeするアーキテクチャ変更を適用した
- ハーネスのログには、この脱出経路を試みたものの設計により阻止された痕跡が多数見られ、過去の強化策の直接的な効果が確認された
ハーネスでセキュリティ強化パイプラインを構築
- Mozillaは過去数年にわたり、GPT 4やSonnet 3.5のようなモデルで高リスクコードを静的解析するLLMコード監査実験を社内で進めてきた
- 初期の実験は可能性を示したが、偽陽性率が高く、規模拡大が難しかった
- セキュリティ問題を安定して検出するagenticハーネスの登場で状況が変わった
- 実際のバグを見つけられる
- 再現できない推測を捨てられる
- 適切なインターフェースと指示があれば、再現可能なテストケースを作成・実行して、コードバグ仮説を動的に検証できる
- Mozillaは2月にAnthropicが送った初期の問題を修正した後、既存のファジング基盤の上に独自のハーネスを構築した
- 当初はClaude Opus 4.6でサンドボックス脱出を探す小規模実験を開始した
- このモデルだけでも、マルチプロセスのブラウザエンジンコードに対する複雑な推論を要する、従来未知だった脆弱性をかなりの数特定した
- 最初はターミナルで過程を直接見守りながら、リアルタイムでプロンプトとロジックを調整していた
- 動作が安定した後は、複数のephemeral VMへ処理を並列化し、各VMが特定の対象ファイルでバグを見つけた後に結果をbucketへ記録するようにした
- 発見サブシステムだけでは十分ではなかった
- 何を探すか、どこを見るか、成果物をどう処理するかを含む、セキュリティバグのライフサイクル全体と統合する必要があった
- 既存イシューとの重複排除、バグ追跡、triage、修正配布まで含まれる
- モデルはハーネスを動かす中核的なプリミティブだが、スケールして有用にするには全体パイプラインが必要だった
- ハーネスはプロジェクト間で再利用できる可能性があるが、パイプラインはコードベースの意味、ツール、プロセスに応じてプロジェクトごとに異なる
- Firefoxエンジニアが流入するバグを処理する流れと密接なフィードバックループを置き、かなりの反復作業が必要だった
Claude Mythos Previewとモデル切り替えの効果
- エンドツーエンドのパイプラインが整えば、新しいモデルが出た際に別モデルへ差し替えるのは簡単になる
- Mozillaは公開モデルでも複数の重大バグを見つけており、このパイプラインのおかげでClaude Mythos Previewの評価機会を得たときにすぐ活用できた
- モデルのアップグレードはパイプライン全体の効果を高めた
- 潜在バグをよりよく見つける
- バグを証明する概念実証テストケースをよりうまく作る
- 病理と影響をよりよく整理する
- Firefox 150 releaseでClaude Mythos Previewが特定した271件のバグを修正したことに加え、149.0.2、150.0.1、150.0.2にも関連修正が含まれている
- 社内では他の方法でもバグ発見を続けており、他プロジェクトと同様にここ数か月で外部報告も大きく増えた
- すべてのバグは適切に修正するために細心の注意を要し、前例のない規模に追いつくため、この数か月は多くの作業と長時間勤務が続いた
- 100人を超える人々が、これまでで最も安全なFirefoxをリリースするためのコード貢献に参加し、パッチ作成・レビューに加えて、パイプラインの構築・拡張、triage、修正テスト、各バグのリリースプロセス管理が行われた
重要な教訓
- ソフトウェアを作る誰もが、いまや現代的なモデルとハーネスを使ってバグを見つけ、コードを強化できる
- シンプルなプロンプトから始めて観察し、反復できる
- 初期プロンプトはこの動画で示された方式と大きくは違わなかった
- 反復を通じてパイプライン最適化と拡張のためのorchestrationやツールが多数追加されたが、内部ループの核心は「このコード部分にバグがあるので見つけてテストケースを作れ」だった
- Firefoxの潜在バグをすべて掘り尽くしたわけではないが、現在の軌道には満足している
- 現在のスキャンは主として、人の判断と自動シグナルを組み合わせて指定した特定のコード領域、つまりファイルと関数に集中している
- 近い将来には、この分析を継続的インテグレーションシステムに統合し、パッチがtreeに入る際にスキャンする計画だ
- モデルは与えられた文脈形式に柔軟に対応し、パッチベースのスキャンはファイルベースのスキャンと同等かそれ以上にうまく機能すると見込まれている
- 現在は危険な時期でもあるが機会も大きく、インターネットを安全にするため共に動く必要がある
よくある質問
-
「271件のバグ」とセキュリティ勧告数が異なる理由
- セキュリティ勧告のWebページでは、内部報告バグを複数のバグがその下に束ねられた「rollup」CVEとしてグループ化している
- Webページは、CVE割り当ての正式な場所であるfoundation-security-advisoriesリポジトリのyamlから生成される
- 一部のブラウザは内部発見イシューにCVE識別子を作成しないが、Mozillaは可能な限り透明性を高めるためこれを公開している
- Firefox 150には内部rollupが3件あった
- CVE-2026-6784: 154件のバグ
- CVE-2026-6785: 55件のバグ
- CVE-2026-6786: 107件のバグ
- 3件の内部rollupの合計は316件で、Claude Mythos Previewで見つけたと発表した271件より多い
- 理由は、Mozillaセキュリティチームが日々Firefoxを攻撃して新たなバグを探しており、その方法がファジングシステム、手動検査、複数モデルを活用した新しいagenticパイプラインの組み合わせだからだ
- 4月リリースでは合計423件のセキュリティバグが修正された
- 2週間前に発表した271件のバグ
- 外部報告バグ41件
- 残る111件は内部発見で、おおむね3種類に分かれる
- このパイプラインでClaude Mythos Previewを使って見つけたが、Firefox 150ではなく別リリースで修正されたバグ
- このパイプラインで別モデルを使って見つけたバグ
- ファジングなど他の手法で見つけたバグ
- Anthropicには今回の最新作業とは別に、3件のCVEが直接クレジットされている
- CVE-2026-6746
- CVE-2026-6757
- CVE-2026-6758
- これらは、数か月前にAnthropic Frontier Red TeamがMozillaへ送ったバグ修正であり、通常手順に従ってそれぞれ固有のCVEが割り当てられた
-
セキュリティ深刻度レーティングの意味
- Mozillaはバグの緊急度を示すためにsecurity severity ratingsをcriticalからlowまで適用している
- sec-criticalとsec-highは、Webページ訪問のような一般ユーザー行動で誘発されうる脆弱性に付与される
- sec-criticalとsec-highの間に技術的差はないが、sec-criticalは公に公開された、または実際の攻撃で悪用されたと分かっている問題にのみ使われる
- sec-moderateは、本来sec-highと評価される脆弱性だが、被害者に異常で複雑な手順を要する場合に付与される
- sec-lowは、安全なcrashのようにユーザー被害から遠い厄介なバグに付与される
- Firefox 150で発表された271件のバグのレーティングは次の通り
- sec-high 180件
- sec-moderate 80件
- sec-low 11件
- Mozillaはcritical/highバグを最重視するが、正確性の問題修正と多層防御のため、moderateやlowのセキュリティバグも優先するのが一般的だ
-
sec-highまたはsec-criticalと実際のエクスプロイトの違い
- sec-highまたはsec-criticalのバグが、そのまま実用的なエクスプロイトを意味するわけではない
- 多くの場合、1件のcritical/highバグだけではFirefoxを侵害するのに十分ではない
- Firefoxは多層防御アーキテクチャを備えており、たとえばJITバグを悪用しても、サンドボックス化されサイトごとに分離されたプロセスでリモートコード実行を得る程度にとどまる
- 実際の攻撃者は通常、複数のエクスプロイトをチェーン化し、1つ以上のサンドボックス層とASLRのようなOSレベル緩和を越えて権限昇格しなければならない
- Mozillaは通常、バグが実際の攻撃者に使われ得るか確認するためのエクスプロイトは作成しない
- sec-high分類は、AddressSanitizerが報告するuse-after-freeやout-of-boundsメモリ問題のような、予測可能なcrash症状に基づく
- 脅威モデルでは、十分な労力があればこうしたバグが悪用可能になり得ると仮定する
- この方式は、悪用可能性分析における偽陰性リスクを減らし、より多くの脆弱性を見つけて修正することにリソースを集中させる
1件のコメント
Lobste.rsの意見
この作業で使ったプロンプトや他の機能も公開してほしい
再現できるように、バグレポートや修正履歴にプロンプトを含めるとよさそう
非Mythosモデルにも触れていたので、この作業の一部は他の人にもすぐ役立ちそう
基本的には「このプロジェクトをセキュリティ問題の観点でレビューし、(ファイル)から始めて、考えられる経路をすべて列挙してほしい」と頼み、その後各項目について「このレポートを検証して概念実証を作ってほしい」と続ければよい
今はOpusを使えば、こういうやり方で何かを見つけられないほうが難しい
何と言おうと、これは本当に印象的だ
Mythosで271件のセキュリティ問題を見つけ、全体では423件を見つけた
そのうち180件は重大度が高く、一部のセキュリティ問題は20年来のものだった
以前に4.6で同様にスキャンしたコードで、Mythosが「271件のバグ」を見つけたかのように示唆されているが、記事が正確にそう言っているわけではない
研究用ハーネスにも同時に変更があったのか気になる
「私たちが修正した複数のsec-high問題のうち1つはXSLT関連だった」という部分は、XSLT削除論争があるので入れたのだと思う
ここでいちばん気になるのは、偽陽性がどれくらい報告されたのかという点だ
モデルが潜在的な脆弱性を2倍ほど多く報告していて、ここに出ているのが確認済みのものなのか気になる
モデルが報告する前に再現までしているのかもわからない
公開されている問題を見ると再現を試みているようなコメントが見えるが、既存のボットがやったものかもしれない
Firefoxがもともとこうした作業をどう処理していたのか、そして今はAIと一緒にどう進めているのかをよく知らないので、もっと詳しい説明があればとても興味深いと思う