90日公開ポリシーは死んだ

 (blog.himanshuanand.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • 90日間の責任ある公開は、LLMによって発見者とエクスプロイト開発速度が増し、防御効果を失った
  • 6週間で11人が同じ致命的な決済検証バグを報告し、同時再発見が明らかになった
  • ReactのパッチdiffはAI支援により、30分で動作するエクスプロイトに変えられた
  • Copy FailとDirty Fragは公開PoCと実際の悪用につながり、エンバーゴが崩壊した
  • 致命的な問題はP0として即時対応し、LLMをセキュリティパイプラインに組み込む必要がある

90日間の責任ある公開モデルが壊れた背景

  • 90日間の責任ある公開期間は、バグ発見者が少なく、エクスプロイト開発が遅かった環境を前提に作られていた
  • この12か月で、セキュリティ担当者、攻撃者、研究者が使うツールは同じような速度で賢くなり、LLMが脆弱性発見とエクスプロイト開発の時間をほぼ0に近づけた、という見立てである
  • 2019年型のモデルでは、Google Project Zeroスタイルのようにベンダーへ90日を与え、その間は次の前提を置いていた
    • 同じバグを見つける人はほとんどいないこと
    • 他の人が見つけても時間がかかること
    • ベンダーがパッチ作成で十分な先行時間を持てること
    • パッチ公開後、攻撃者がそれをリバースエンジニアリングして動作するエクスプロイトを作るまでに数日または数週間かかること
  • これらの前提はすべて崩れ、90日の窓はユーザーを守るどころか、すでにバグを持っている者たちに90日の先行時間を与える仕組みになった

事例1: 6週間で11人が同じ致命的バグを報告

  • 4月末、ある企業に深刻なバグを報告したところ、トリアージチームは3月に最初の報告があり、自分は11人目の報告者だと返答した
  • バグの内容は、Webサイトで商品を購入した後、攻撃者が自分で改ざんした応答をサーバーに返しても、応答に対する署名検証がなく、サーバーがそのまま受け入れてしまう構造だった
    • たとえば、5,000ドルの商品を0ドルで買ったり、実際の決済なしに購入完了として処理できた
  • 約6週間で異なる11人が同じ致命的バグを見つけたことから、LLM支援ハンターがほぼ同時に同じ脆弱性へ収束するパターンが明らかになった
  • BlueWater CTFの知人は数か月前から、互いに無関係なレポーターやワークフローがLLM支援によって同じバグへ集まる現象を指摘していた
  • トリアージ側でも同じ現象が観測されている
    • @d0rskyは、LLMプロンプト、スキル、自動化により、新しい脆弱性が見つかると数日以内に同じ根本原因の重複報告が殺到すると書いている
    • 研究者がこれほど速く再現できるなら、パッチ前にブラックハットも同じことができるという懸念が強まる
  • 10人が報告していたなら、報告していない人もいる可能性があり、同じLLMは善意の研究者だけでなく誰にでも開かれている
  • CVEクレジットとバグバウンティは1人しか得られないため、残りの9人や、そもそも報告しなかった人は90日の時計に縛られていない
  • 90日公開ウィンドウはこの状況でユーザーを守れず、すでにバグを持つ者たちに時間を稼がせる装置になっている

事例2: Reactのパッチから動作するエクスプロイトまで30分

  • Reactは複数のセキュリティ問題を修正し、公開ブログ記事を出した
  • ローカルテストアプリを対象に、パッチを読み、動作するエクスプロイトを作るまで30分かかった
  • この公開済み問題はサービス拒否（DoS）で、AIがdiff理解、脆弱なコード経路の特定、PoC作成の大半を処理した
  • 以前は、公開パッチを動作するn-dayエクスプロイトへ変えるのに、熟練したリバースエンジニアが数日から数週間を費やしており、この時間差が管理者が更新できる安全網だった
  • 今では単純なバグは数分、複雑なバグでも数時間単位になり得て、熟練したリバースエンジニアは必須ではなくなった
  • パッチが出た瞬間にエクスプロイトも存在すると仮定すべきであり、次のメンテナンスウィンドウまで展開を遅らせるやり方は通用しない

事例3: Linuxカーネルで相次いで起きたCopy FailとDirty Frag

  • 直近2週間でLinuxカーネルに2つの致命的脆弱性が連続して現れ、どちらも公開エクスプロイトがあり、主要ディストリビューションに影響した

  • Copy Fail

    • 4月29日、Xint CodeがCopy Failを公開した
    • Xint CodeはTheoriのチームであり、DEF CON CTFで9回優勝したチームとして紹介されている
    • Copy FailはCVE-2026-31431で、カーネルのcryptoサブシステムにある直線的なロジック欠陥と説明されている
    • レースコンディションなしで100%信頼でき、732バイトのPythonスクリプトで2017年以降に配布されたすべてのLinuxディストリビューションでroot権限を取得できるという
    • Ubuntu、RHEL、Amazon Linux、SUSEなど主要ディストリビューションが影響を受ける
    • AIを使ってカーネルのcrypto/サブシステムを約1時間自動スキャンして発見し、9年間露出していた脆弱性だったという
    • 技術分析はXintの記事にある
    • mainlineコミットa664bf3d603dでパッチが出ており、algif_aeadモジュール無効化という緩和策もあった
    • その後、イランの攻撃者がこの脆弱性を利用してUbuntuサーバーを侵害し、DDoSキャンペーンのノードとして再利用した兆候が観測されたという
    • AIで発見されたカーネル権限昇格脆弱性が、公開PoCと国家レベル攻撃者の武器化へ至るまでに数日しかかからなかった

  • Dirty Frag

    • 約1週間後の5月7日、Hyunwoo Kim(@v4bel)がDirty Fragを公開した
    • Dirty FragはCVE-2026-43284とCVE-2026-43500をつなげた脆弱性である
    • カーネルのIPSec ESP（esp4/esp6）とRxRPCネットワーキングモジュールにある2つの脆弱性をチェーンしている
    • Copy FailやDirty Pipeのようなバグ系統、同じpage-cache corruption手法だが、攻撃経路は異なる
    • Copy Failの緩和策を適用してもDirty Fragは動作する
      • algif_aeadをブラックリスト化しても、Dirty Fragはそのモジュールを使わない
    • 非特権ユーザーからrootへ決定的に昇格でき、Ubuntu、RHEL 10.1、openSUSE、CentOS Stream、AlmaLinux、Fedora 44など主要ディストリビューションで動作するという
    • コンパイルと実行は1行コマンドで可能である

  • Dirty Fragの公開過程とエンバーゴ崩壊

    • Hyunwoo Kimは4月29〜30日に[email protected]へ報告し、パッチを公開提出した
    • 5月7日、linux-distrosメーリングリストと調整し、5日間のエンバーゴに合意した
    • その日のうちに数時間以内で、無関係な第三者がESP脆弱性の詳細なエクスプロイト情報を公開し、エンバーゴが破られた
    • ディストリビューションメンテナーたちと相談した後、HyunwooはDirty Fragの完全分析、エクスプロイトコード、動作PoCを公開した
    • その時点で、パッチを提供しているLinuxディストリビューションは0件だった
    • 現時点ではCVE-2026-43284、つまりESP側にのみmainline修正があり、CVE-2026-43500、つまりRxRPCコンポーネントにはまだupstreamパッチがないという
    • Ubuntu、Red Hat、Tenableなどが独自の勧告を出している

  • Dirty Fragの実際の悪用

    • Microsoft Defenderチームは、公開後24時間以内に限定的な実際の悪用を確認した
    • 攻撃者はSSHアクセスを取得し、ELFバイナリを配布し、suでroot権限を得て、認証設定を変更し、セッションファイルを削除し、横移動を行ったという
    • CTS(@gf_256)は「responsible disclosure is dead🤦」と要約した

実際に死んだもの

  • 90日公開ウィンドウは修正可能な問題ではなく、終わったモデルである
  • このモデルは発見者が少なく、エクスプロイト開発が遅い世界に合わせていたが、LLMは発見者を増やし、エクスプロイト開発を加速させる
  • 互いに無関係な10人が6週間以内に同じバグを見つけ、AIがpatch diffを30分で動作エクスプロイトに変えられるなら、90日の窓は誰も守れない
  • Copy FailはAIスキャンから公開PoC、国家レベル攻撃者の武器化まで数日で進んだ
  • Dirty Fragは、同じバグ系統を独立に見つけた第三者のため、エンバーゴが数時間で崩壊した
  • 同じ脆弱性が複数の研究者とAIツールにより同時に独立再発見される環境では、公開調整の維持は難しい
  • 月次パッチサイクルも終わった
    • 脆弱性と修正の間に30日の窓を置く考え方は、攻撃者がリリーストレインより遅いことを前提にしている
    • MicrosoftがDirty Fragの実際の悪用を24時間以内に確認した状況では、月次メンテナンスウィンドウは安全余裕ではなく攻撃ウィンドウになる
  • 勧告を待つやり方も終わった
    • 防御側がCVE説明を読んでいる間に、攻撃側はgit log --diff-filter=Mを読んでいる
    • 勧告はdownstreamの成果物であり、patch diffこそがシグナルになる

業界が変えるべき対応

  • すべての致命的セキュリティ問題をP0として扱い、即座に修正すべきだという結論である
  • 「24時間以内」「次のスプリントで」「影響評価後に」ではなく、やっていることを止めてすぐ直す水準が必要だ
  • 本番展開が複雑で変更管理が必要な理由はあるが、脅威環境は変更管理手順を待ってくれない

  • ベンダー

    • 致命的バグ報告が入った瞬間から時間は流れ始める
    • トリアージ完了時点でも、エンジニアリングへ渡った時点でもなく、報告が届いた瞬間が基準である
    • 誰かが報告したなら、すでに10人が持っており、そのうち少なくとも1人は友好的ではないと仮定すべきだ

  • 研究者

    • 致命的バグを長く保持せず、可能な限り最短の公開ウィンドウを求めるべきだ
    • ベンダーが1週間以内に直せないなら、それは公開の問題ではなくベンダーの問題である
    • かつての「時間を与える」という礼儀は、自分が唯一の発見者であるときに意味があったが、今は唯一の発見者ではない可能性が高い

  • 脆弱性管理

    • 脆弱性管理はリアルタイムであるべきだ
    • 「週次スキャン、スプリントでトリアージ、周期に合わせてパッチ」は、攻撃者がすでに去った後のタイムラインである
    • 致命的問題に対する新たな最大応答時間は数日ではなく数時間であり、それでも遅すぎるかもしれない

ブルーチームがLLMを防御パイプラインに入れるべき理由

  • 攻撃側はすでにLLMをエクスプロイトパイプラインへ統合しており、防御側も同じ速度で動かなければならない
  • コードpush時点でLLMを統合すべきだ
    • すべてのpull request、merge、deployで、AI支援のセキュリティレビューをCIパイプラインの一部として実行する必要がある
    • linterやunit testのようにpush時点で実行すべきであり、四半期ごとの監査や事後点検であってはならない
    • 脆弱性があるなら、本番到達前に捕まえるべきであり、PRレビューで直すコストはCVE公開後に直すコストよりはるかに低い
  • パッチ分析にもLLMを統合すべきだ
    • upstream依存関係がセキュリティパッチを出したら、パイプラインが自動でdiffを取得し、変更内容を分析し、自社コードベースへの影響有無を判断し、フラグを上げるべきだ
    • 人がメーリングリストを読んでJiraチケットを起票するやり方に頼らず、公開リポジトリにパッチが上がった直後、数分以内に自動で起きる必要がある
    • Xint Codeが1時間の自動スキャンでCopy Failを見つけたなら、自社依存関係も同じ方式でスキャンすべきだ
  • 依存関係スキャンにもLLMを使うべきだ
    • サプライチェーンは最も弱い推移的依存関係の強さまでしか強くない
    • AIベースの依存関係スキャナは、依存関係ツリー内で脆弱性の影響を追跡し、影響を受けるバージョンを表示し、アップグレード経路まで提案できる
    • 週次ではなく継続的に実行すべきだ
  • パッチリリース前にAIでパッチをテストすべきだ
    • React事例のように、LLMが30分でパッチをエクスプロイトへ変えられるなら、防御側はパッチ公開前に同じツールで先に検証すべきだ
    • パッチが本当に問題を修正しているか、新たな問題を生んでいないか確認すべきだ
    • 回帰テスト生成や、同じパターンがコードベースの別の場所にもないかを確認するのに活用すべきである
  • 「脆弱性の存在」と「脆弱性の悪用」の間の窓は0に近づいており、防御側も攻撃側と同じ速度で自動化しなければならない
  • より多くのzero-dayが、より速く実環境で悪用されるようになり、その理由は同じツール、低くなった参入障壁、増えた発見者、短くなったタイムラインにある
  • この転換の中で生き残るチームは、強制的に追い込まれる前にAIをセキュリティパイプラインの第一級コンポーネントにしたチームである

結論

  • Dirty Fragの勧告を読むシステム管理者が、パッチはなく、エクスプロイトはすでに公開され、Microsoftは実際の悪用を確認しており、緩和策はIPSecモジュール無効化という状況で400台のサーバーを触らなければならない現実が、新たな基準になった
  • 90日公開ポリシー、月次パッチサイクル、公開と悪用の間に時間があるという前提はすべて死んだ
  • まだ残っているのは、素早く動き、強く自動化し、致命的バグを本当の緊急事態として扱う能力だけである
  • 既存モデルを壊したAIの波は同時に、高速パッチ、自動スキャン、リアルタイム脅威インテリジェンス、AI支援コードレビューのような新しいモデルも可能にしている
  • ツールはすでに存在しており、防御側が攻撃側より先に使うかが核心であり、現時点では攻撃側がその競争で先行している

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Lobste.rs の意見

  • しぶしぶながら同意せざるを得ない。うちの会社でもこの件を調査したが、パッチからエクスプロイトまでにかかる時間はほぼ即時のレベルだった

  • 責任ある開示 ポリシーは、そもそも人々が互いに礼儀として信じているふりをしていただけの虚構だった。もともと空気に合わせて従っていただけで、LLM ベースの脆弱性発見ツールがその実態を露わにしたにすぎない

  • この文章自体からも LLM が書いたような匂い がするのが、かなり皮肉に感じられる

    • 言っていることは筋が通っている。独創的なアイデアがあるなら、誰かに先を越される前に公開しなければならない。批判的思考と自己省察 は死に、考えが浮かんでから39分以内にブログへ載せないと誰かが先にやってしまう :P
    • 私にはそうは見えない。こういう文体は LLM 以前の技術記事 にもずっと前からあったし、主要な LLM はたいていこの文章とは少し違う書き方をする
    • 恐怖を煽る広告のように読める
    • 良くも悪くも、もうただこういう流れになっている気がする

  • もしかすると死んだのは、ミッションクリティカルな場面で使われる 手作りの職人芸的なブティック C プログラム の時代なのかもしれない