Fragnesia およびこれに類する攻撃：ページキャッシュの脆弱性が再発し続けるケース

数週間前、私は Copy-Fail (CVE-2026-31431) について執筆し、脆弱性のあるカーネルにもかかわらず、Red Hat OpenShift の多層防御アプローチがどのようにコンテナエスケープを防いだかについて説明しました。私は OpenShift コンテナからのエスケープを試み、すぐに Pod 内の root 権限を取得できましたが、それでもホストへエスケープすることはできませんでした。カーネルの脆弱性は実在していました。エクスプロイトのパスも実在していました。そして、防御は依然として機能していました。 

この記事をまとめている間に、DirtyDecrypt (CVE-2026-31635) という別の関連するバリアントが、エクスプロイトに関する議論や概念実証 (PoC) の報告がされている中、一般に広まり始めました。その時点で、約 14 日間で 4 つの主要な Linux の権限昇格の脆弱性が確認されており、それらはすべて、同じ大まかなパターンのバリエーションを悪用したものでした。

それは、私にとって検討を要する最も重要な要素でした。

ある時点から、これらを個別の CVE として見るのをやめ、構造的な問題として捉えるようにしました。異なるサブシステム、エクスプロイトの異なるパスがありますが、基本的な仕組みは同じです。カーネルのページキャッシュ内でコピーオンライト (COW) の挙動を操作し、本来は不変であるはずのファイルを改ざんして、特権を昇格させます。

もし現在、本番環境のインフラを運用しているなら、その事実を認識した途端、議論の行方は一気に変わってくるでしょう。個々のCVE を 1 つずつ追いかけることは、もはやセキュリティ戦略というよりは、雪崩が押し寄せる中で舌を使って雪の結晶を捕まえようとするようなものに感じられてきます。その結果は決して良いものではありません。 

重要なのは、次のバリアントが必然的に出現した際、アーキテクチャが依然として回復力を維持できるかどうかです。

なぜなら、現時点では、おそらく出現するからです。

異なる CVE だがパターンは同じ

過去 2 週間の間に、研究者は複数の関連する脆弱性を公開しました。一般的なページキャッシュ操作を標的とする Copy-Fail、ESP/XFRM および RxRPC パスに及ぶ Dirty Frag、ESP-in-TCP を標的とする Fragnesia、および現在は rxgk 関連で公開されている DirtyDecrypt などがあります。実装の詳細は異なりますが、攻撃の根本的な考え方は驚くほど一貫しています。研究者はカーネルのネットワークコードのある領域で概念的な弱点を見つけると、隣接するサブシステムを追跡し、同様の前提条件や欠落している安全策を探し始めます。そして、そうした弱点を次々と発見しているのです。

この繰り返されるパターンは、個々の CVE 番号よりも私にとって大きな懸念材料です。

ROSA クラスタを起動し、OpenShift に対して直接 Fragnesia をテストすることにしました。そのクラスタは、脆弱な 5.14.0-570.113.1.el9_6.x86_64 カーネルを搭載した Red Hat Enterprise Linux (RHEL) CoreOS 9.6 上で OpenShift 4.21.15 を実行していました。脆弱なサブシステムが存在していました。理論上、この環境は悪用可能であるはずでした。

私が理解したかったのは、単にカーネルが脆弱であるかどうかということではありませんでした。それはすでに分かっていたからです。私が知りたかったのは、さまざまなセキュリティ構成において、エクスプロイトチェーンがどこから始まるのか、ということでした。

まず、デフォルトの OpenShift 保護機能を備えた、完全に標準的な Pod をデプロイしました。特別な設定は一切ありません。権限の昇格も、緩和された SCC もありません。sleep infinity を実行する、ごく普通の Fedora コンテナです。

エクスプロイトチェーンは、ほぼ即座に失敗しました。

攻撃が本格的に進行する前に、ユーザーの namespace の作成がブロックされました。脆弱性のあるサブシステムは依然として存在していましたが、コンテナはそもそも危険なコードパスに到達するために必要な権限を一切取得できませんでした。OpenShift のデフォルトの SCC (security context constraint) と SELinux の強制が組み合わさり、エクスプロイトが実際に動き出す前にその扉を閉ざしたのです。

その点は驚くことではありませんでした。

私がより興味を持ったのは、次のシナリオ、つまり多くの実際の組織で実際に運用されているような構成でした。

私は、anyuid SCC を使用してワークロードを作成し、コンテナをユーザー ID (UID) 0 として明示的に実行しました。これはブラウンフィールド環境 (レガシーアプリケーションが「最小権限の原則」に基づいて設計されておらず、組織が「アプリに必要だから」という理由で妥協しがちな既存の環境) では極めて一般的なことです。

Pod 内では、root 権限を持っていました。

それでも、エクスプロイトチェーンは失敗しました。

anyuid を設定しても、SELinux が引き続き container_t ドメインの制限を適用し、権限昇格の継続に必要な namespace の操作が阻止されました。これこそが、OpenShift のモデルにおいて多くの人が見落としがちな点だと思います。つまり、セキュリティ層は意図的に重複しているのです。1 つの制御を緩和しても、残りの境界が自動的に解消されるわけではありません。

その時点で、私は常識的なアプローチに留まることをやめることにしました。

特権付き SCC、root ユーザー、制限のない seccomp を組み合わせ、意図的に危険な構成を構築しました。これは、ホストを直接引き渡すこと以外で、OpenShift のワークロードに設定できる最も緩い構成と言えます。

そしてついに、事態が動き始めました。

ユーザー namespace が機能しました。unshare -U が成功したのです。エクスプロイトチェーンは、これまでのシナリオでは決して許されなかった形で進行し始めました。多くの Kubernetes ディストリビューションでは、このあたりで、「セキュリティ調査」から「インシデント対応」へと移行します。

それでも、エクスプロイトは失敗しました。

Fragnesia は、単に namespace の作成を必要とするだけではありません。攻撃者が脆弱なネットワークパスにアクセスするために必要な権限を取得できるよう、namespace 内で UID/GID マッピングを正常に完了させる必要があります。

その最終ステップがブロックされたのです。

特権付き SCC、root、制限のない seccomp を使用しても、SELinux は /proc/self/uid_map への書き込みを拒否しました。UID マッピングが正常に行われなかったため、権限昇格のチェーンは崩壊しました。namespace 内の root 特権がなければ、XFRM/ESP にアクセスできません。サブシステムへのアクセスがなければ、ページキャッシュの破損も発生しません。

カーネルには依然として脆弱性がありましたが、エクスプロイトは失敗しました。この違いに留意することは重要です。

このテストを通じて改めて確信したのは、私がかねてから信じていたこと、すなわち、優れた多層防御は、とくに事態がうまくいかなくなったときにこそその価値を発揮するということです。それは、すべてが完璧に設定されているときではありません。すべてのワークロードが初期状態かつ最小限の特権で、セキュリティチームが望むすべてが揃っているときではないのです。実際の環境は混沌としています。制御は緩みがちです。レガシーワークロードも存在します。運用上の妥協は常に発生します。

重要なのは、そのような妥協がいくつか発生した後も、アーキテクチャが依然として機能し続けるかどうかです。

今回のケースでは、機能し続けました。

複数のセキュリティ層を同時に弱体化させた後でも、SELinux は依然としてコンテナを基本的に信頼できないものと扱い、エクスプロイトを完了するために必要な最終的な権限昇格のステップを阻止しました。

これこそが、「セキュリティ機能」と一貫性のあるセキュリティアーキテクチャとの違いです。私にとっては、個々の Fragnesia の CVE よりも、この広範なアーキテクチャに関する議論の方が重要です。なぜなら、ここ数週間の出来事が私たちに示してくれたことがあるとすれば、この脆弱性ファミリーの進化は、おそらくまだ終わっていないためです。

組織が自問し始めるべき運用上の問いは、もはや「CVE-2026-46300 にパッチを適用したか？」ではありません。真の問いは、「来週の火曜日に、誰も注目していなかった別のサブシステムを標的とする CVE-2026-XXXXX が公開されたとき、運用上何が起こるか？」ということです。

エクスプロイトは進化するが、シグナルは変わらない

率直に言って……現時点では、もはやこれは仮定の話ではなくなっているように感じられます。

また、この点において、Red Hat Advanced Cluster Security for Kubernetes は、単なる CVE に基づく考え方よりもはるかに価値が高いと私は考えています。この文脈における Red Hat Advanced Cluster Security の興味深い点は、Fragnesia を具体的に認識していることではなく、脆弱性自体が変わったとしても、これらのエクスプロイトチェーンを取り巻く動作パターンは、多くの場合に識別可能であるという点です。

Web アプリケーションコンテナが突然ユーザー namespace を作成するのは異常なことです。/bin/su を実行するアプリケーションのワークロードは異常です。エクスプロイトが Copy Fail、Dirty Frag、Fragnesia、DirtyDecrypt、または研究者が来週考案するどのような名称で呼ばれようとも、これらのシグナルは依然として重要です。

CVE は変わっても、こうしたケースにおける挙動は変わりません。

これが重要なのは、脆弱性の公開サイクルが加速しており、多くの組織が運用上の不安定さを招くことなく大規模なクラスタ群にパッチを適用するには、現実的に追いつけないほど速くなっているためです。 アーキテクチャと動作の可視化によって、時間を稼ぐことができます。この時間こそが、制御された修復計画を実行できるか、それとも次の 18 時間をインシデント対応チームに閉じ込められ、どのクラスタが危険にさらされているかを推測することに費やすかの分かれ目になることもあります。

これは、フリート規模での運用においても同様です。

ラボで 3 つの Pod をテストするのは容易です。しかし、本番環境のワークロードを稼働させたまま、数十や数百ものクラスタにわたってポリシー変更を調整するのは、まったく別の問題です。そこで、Red Hat Advanced Cluster Management for Kubernetes は、場当たり的な対応から統制されたロールアウトへと状況を一変させます。クラスタを 1 つずつ手動で監査し、危険な設定を手動で特定し、チーム間でセキュリティポスチャの変更を手動で調整する代わりに、一貫したポリシーを一元的に策定し、それをすべての場所に一度に展開します。

数日おきに新しいバリアントが出現している状況では、この違いが極めて重要になります。

私の Red Hat OpenShift on AWS (ROSA) クラスタでは、テスト期間中ずっとカーネルに脆弱性が残っていました。脆弱なサブシステムも存在したままでした。エクスプロイトの前提条件も技術的には満たされていました。

それでもエクスプロイトチェーンは崩壊し続けました。多層的な制御が、複数のポイントで権限昇格を阻止していたからです。

そして、私がこの記事を執筆している最中に、DirtyDecrypt が一般に広がり始めました。

エクスプロイトの根本的な考え方は同じです。対象となるサブシステムは異なりますが、すでに機能している防御策は同じです。

これは運ではありません。これがアーキテクチャの力です。これこそが「多層防御」なのです。

詳細情報

• When AI finds the bugs: Why defense in depth was always the answer
• OpenShift を無料でお試しください
• OpenShift Platform Plus の詳細