全Linuxでroot昇格、パッチなしのDirty Frag
Copy Failの次が来た。「Dirty Frag」は主要なLinuxディストリビューションすべてでroot権限を奪取できる脆弱性だ。CVEは未割り当て、パッチは存在しない。
何が起きているのか
Linuxカーネルのセキュリティを揺るがす脆弱性が、わずか1週間の間に2件続いた。
5月初旬に明らかになった Copy Fail（CVE-2026-31431）の余韻が続く中、ヒョンウ・キム氏はDirty Fragと名付けた新たな脆弱性クラスを公開した。2つの脆弱性をチェーン（連鎖）させ、Ubuntu・RHEL・Fedora・CentOS Stream・AlmaLinux・openSUSE Tumbleweedといった主要ディストリビューションのすべてでroot権限昇格を達成する。
Copy Failの直後にLinux全体が影響を受ける権限昇格が出てきた。CVE番号もパッチも存在しない状態で exploit が公開されている。
事態をさらに複雑にしているのが、公開の経緯だ。責任ある開示（いわゆるエンバーゴ）の期間中に無関係の第三者が exploit を公開してしまい、計画が崩れた。キム氏はディストリのメンテナーと協議の上、全情報を即時公開せざるを得なかった。
即時の強制公開──これがもっとも危険な点だ。パッチが存在しないまま、完全に動作するPoC（概念実証コード）がGitHub上に誰でもアクセスできる状態で置かれている。
なぜ「Dirty」シリーズと呼ばれるのか
Dirty Fragは、2022年に発見されたDirty Pipe（CVE-2022-0847）、そして今年のCopy Failと同じバグクラスに属する。
Dirty Pipeがパイプバッファを上書きしたのに対し、Dirty Fragが「汚染」するのは struct sk_buff（ソケットバッファ）の frag メンバーだ。これがそのまま命名の根拠になっている。
仕組みの核心は、ページキャッシュの書き換えにある。
Linuxカーネルは、ファイルを読み書きするたびにその内容をメモリ上に「ページキャッシュ」として一時保持する。通常このキャッシュは書き込み権限のないプロセスからは変更できないが、Dirty Fragはその前提を崩す。
splice()（ゼロコピー転送）を使って /usr/bin/su や /etc/passwd などのページキャッシュページをネットワークバッファのフラグメントとして植え込むと、カーネルはそのページを「自分が所有するバッファ」だと誤解したまま暗号処理（インプレース復号）を行う。結果として、読み取り専用のはずのシステムファイルがメモリ上で書き換えられる。
2つの脆弱性が互いの弱点を補う
Dirty Fragがとくに厄介なのは、2脆弱性の連鎖という設計にある。それぞれ単独では特定の環境でしか機能しないが、チェーンすることで「どちらかが必ず刺さる」構造になっている。
| ESP経路 xfrm-ESP Page-Cache Write |
RxRPC経路 RxRPC Page-Cache Write |
|
|---|---|---|
| 権限 要件 |
ユーザー名前空間の 作成権限が必要 |
不要 (一般ユーザーで動作) |
| 攻撃 対象 |
/usr/bin/su を シェルコードで上書き |
/etc/passwd の root行を書き換え |
| 書き換え サイズ |
4バイト単位 （任意値を直接指定） |
8バイト単位 （鍵Kのブルートフォースで間接制御） |
| モジュール 搭載 |
主要ディストリで 標準搭載 |
Ubuntu標準搭載 他ディストリは非搭載 |
| 単独で 効かない 環境 |
UbuntuでAppArmor により名前空間が ブロックされた場合 |
Ubuntu以外の ほとんどの ディストリ |
| チェーン後 の役割 |
Ubuntu以外の 主要ディストリを カバー |
Ubuntuを カバー |
xfrm-ESPによるページキャッシュ書き込み
IPsec（インターネット通信を暗号化するプロトコル）のESP処理を担う esp_input() に欠陥がある。spliceで植え込まれたフラグメントを持つskbに対して、カーネルが本来行うべきコピー（skb_cow_data()）をスキップし、そのページキャッシュに直接インプレース復号を実行してしまう。
攻撃者はこの処理を通じて、ターゲットファイルの任意の4バイトをコントロールできる。/usr/bin/su の先頭192バイトを静的なrootシェルELFで上書きし、setuidビットが立ったままのsuを実行するだけでroot shellが得られる。
ESPパス経由の攻撃には、ユーザー名前空間を作成する権限（unshare(CLONE_NEWUSER)）が必要だ。Ubuntuは場合によってAppArmor（アクセス制御フレームワーク）でこの操作を制限するため、この経路だけではUbuntuをカバーできない。
RxRPCによるページキャッシュ書き込み
そこでUbuntu向けの「補完」として機能するのがRxRPC経路だ。AFS（Andrew File System）の認証プロトコルRXKADを処理する rxkad_verify_packet_1() が、spliceで植え込まれたページに対してインプレース復号を実行する。
この経路では、ユーザー名前空間の作成権限が不要だ。攻撃者はキー（add_key()）を自由に設定でき、fcrypt_decrypt(C, K) の結果がターゲットの値と一致するKをユーザー空間でブルートフォースする。狙いは /etc/passwd の1行目（rootエントリ）の書き換えで、パスワードフィールドを空文字列にすることでPAMの「nullok」設定が認証なしでrootアクセスを通してしまう。
一方、rxrpc.koモジュールはほとんどのディストリビューションでデフォルト搭載されない。しかしUbuntuではデフォルトでロードされる。つまり、Ubuntuでの「ESPの弱点」をRxRPCが、他のディストリでの「RxRPCが使えない弱点」をESPが、それぞれ補う設計になっている。
影響を受けるバージョン
キム氏の公開情報によれば、ESP側の脆弱性は2017年1月のコミット以降から現在のアップストリームまで、RxRPC側は2023年6月以降から現在まで影響を受ける。実質的な脆弱性の存続期間は9年にのぼる。
テスト済みの環境は以下の通りだ。Ubuntu 24.04.4（カーネル6.17.0）、RHEL 10.1（6.12.0）、openSUSE Tumbleweed（7.0.2）、CentOS Stream 10（6.12.0）、AlmaLinux 10（6.12.0）、Fedora 44（6.19.14）。
また、Dirty FragはCopy Failの緩和策をバイパスする。algif_aeadモジュールのブラックリスト化というCopy Failへの対策を施済みの環境でも、Dirty Fragは動作する。
現時点での対処
AlmaLinuxはアップストリームのESP修正（コミット f4c50a4034e6）をバックポートしたパッチカーネルをテストリポジトリで公開した。Red Hatからの正式パッチを待たずに独自対応を進めるという、迅速な判断だ。各バージョンの対象カーネルはAlmaLinux 8が 4.18.0-553.123.2.el8_10、AlmaLinux 9が 5.14.0-611.54.3.el9_7、AlmaLinux 10が 6.12.0-124.55.2.el10_1 以降となる。
RxRPC側のパッチはまだアップストリームにマージされていない。キム氏が4月29日に netdev メーリングリストにパッチを投稿しており、現在レビュー中の状態だ。
今すぐ再起動できない環境向けには、脆弱なカーネルモジュールを無効化する一時的な回避策がある。
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"このコマンドにより、3つのモジュール（esp4、esp6、rxrpc）の読み込みを阻止し、すでにロード済みの場合はアンロードする。IPsecのESPモードを使ったVPNや、AFS（Andrew File System）を利用しているシステムでは通信に影響が出る点には注意が必要だ。
また、攻撃がすでに行われている可能性を疑う場合は、ページキャッシュをクリアして改ざんされたコピーをメモリから追い出すことが推奨されている。
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'まずパッチカーネルへの更新が最優先だ。 再起動を含む計画的なメンテナンスが取れる環境なら、上記の回避策より確実なパッチ適用を優先すること。
なぜこれほど危険なのか
Dirty Fragが際立つのは、技術的な精巧さだけではない。
競合状態（レースコンディション）を必要とする脆弱性は、攻撃のタイミングが難しく失敗率も高い。対してDirty Fragは確定的なロジックバグだ。タイミングウィンドウに依存しない、カーネルがパニックしない、成功率が極めて高いという3点が組み合わさっている。
さらに、今回の事態はエンバーゴという安全網が機能しなかったことを示している。キム氏は4月29〜30日に脆弱性情報とパッチをカーネルチームに提出し、5日間のエンバーゴを設定した。しかし5月7日にESP exploit が第三者により公開され、計画は崩れた。パッチが揃う前に exploit が世に出てしまうというシナリオは、開示プロセスの運用の難しさを改めて突きつけている。
|
4月29日
rxrpc脆弱性を報告・パッチ投稿
[email protected]に詳細を提出。同日、netdevメーリングリストにパッチを公開投稿
4月30日
ESP脆弱性を報告・パッチ投稿
[email protected]に詳細と完全動作のexploitを提出。netdevにパッチを公開投稿
5月4日
Shared-fragアプローチのパッチ投稿
Kuan-Ting Chen氏がESP修正のshared-fragアプローチをnetdevに投稿
5月7日
(UTC) マージESPパッチがnetdevツリーに取り込まれる
コミット f4c50a4034e6。同日、linux-distrosへ詳細を提出しエンバーゴを設定（終了予定：5月12日）
5月7日
(UTC) エンバーゴ破棄第三者がESP exploitを公開
無関係の第三者がexploit全文をインターネット上に公開。計画した5日間の調整期間が崩れる
5月8日
(JST) 即時全公開Dirty Frag 全文・exploit を公開
ディストリのメンテナーと協議の上、ヒョンウ・キム氏がDirty Fragの全技術情報とexploitをoss-securityに投稿。CVEなし・パッチなしの状態での公開となる
|
Copy Failの一週間後に同一バグクラスの次弾が来た事実は、Linuxカーネルのページキャッシュ周辺の設計に根深い問題が潜む可能性を示唆している。「次の Dirty ○○」が存在するかどうか、それはまだ誰にもわからない。
参照元
他参照
