Dirtyfrag: ユニバーサルLinux LPE

概要

Dirty Frag は、全主要Linuxディストリビューションでroot権限を取得できる LPE（特権昇格）脆弱性。
2つの未修正脆弱性 を連鎖利用し、即時にroot権限を奪取可能。
パッチやCVEは未提供、責任ある開示スケジュールが破綻したため公開。
影響範囲が広範 で、緊急の対策が必要。
モジュールの無効化コマンド と 詳細技術情報URL が提供されている。

Dirty Frag: Universal Linux LPE脆弱性レポート

Dirty Frag は、全主要Linuxディストリビューションに影響する ローカル特権昇格（LPE）脆弱性。
過去の Copy Fail 脆弱性と同等の深刻な影響。
2つの未修正脆弱性 を組み合わせて利用する手法。
- 脆弱性1の詳細（kernel.org）
- 脆弱性2の詳細（lore.kernel.org）
パッチ未公開、CVE番号も未発行。
責任ある開示スケジュールが破綻 し、保守者の要請で公開に至る。

一時的な緩和策

脆弱なカーネルモジュール（esp4, esp6, rxrpc）のロードを無効化するコマンド例：

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"

恒久的な対策にはカーネルパッチが必須。

技術詳細と追加情報

詳細な技術情報やエクスプロイトコードはdirtyfrag.ioで公開。
公開された PoC（概念実証）コード は、/usr/bin/su等の実行ファイルをrootシェルに置き換える内容。
攻撃者はローカルユーザー権限からroot取得が可能。
影響範囲は極めて広範、クラウド環境やオンプレミス問わずLinuxサーバ全般。

参考：脆弱性利用の流れ（概要）

ネットワーク名前空間・ユーザー名前空間 を悪用し、カーネルの脆弱性をトリガー。
Netlink/XFRMインターフェース を通じて、任意のカーネルメモリ操作を実現。
ELFバイナリ（例：su）を任意のシェルコードで上書き、rootシェル取得。

対策と推奨アクション

直ちに該当モジュールの無効化 を実施。
ディストリビューション公式の脆弱性情報 や パッチ提供状況 を随時確認。
サーバ管理者・運用担当者は緊急対応体制の構築。
- モジュールの恒久無効化
- サーバアクセス監査強化
- root権限取得イベントの即時検知

まとめ

Dirty FragはLinux環境への重大なリスク。
パッチリリースまでの間、モジュール無効化等の緩和策を徹底。
公式発表やdirtyfrag.ioの情報に継続的な注意 が必要。

Hackerたちの意見

「禁輸が破られたので、これらの脆弱性に対するパッチやCVEは存在しません。」重要な点: 「Copy Failがこの研究を始めるきっかけでした。特に、Dirty Frag脆弱性チェーンのxfrm-ESPページキャッシュ書き込みは、Copy Failと同じシンクを共有しています。しかし、algif_aeadモジュールが利用可能かどうかに関係なくトリガーされます。つまり、一般に知られているCopy Failの緩和策（algif_aeadブラックリスト）が適用されているシステムでも、あなたのLinuxはDirty Fragに対して依然として脆弱です。」緩和策（私はテストや確認はしていません！）: 「責任ある開示スケジュールと禁輸が破られたため、どのディストリビューションにもパッチは存在しません。脆弱性が発生するモジュールを削除するには、以下のコマンドを使用してください。」 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" 緩和策に関する会話では、再起動が必要か、すでに悪用されたマシンで上記の後にこれを実行する必要があるようです: sudo echo 3 > /prox/sys/vm/drop_caches

└

「sudo」が入った「sudo echo 3 > /proc/sys/vm/drop_caches」は何も効果がないよ。echoだけが実行されて、書き込みはされないからね。もしマシンがすでに侵害されていたら、そんなことをしても手遅れだよ。ディスクイメージ全体を再構築する必要がある。だって、そこにあるものは全部危険にさらされているかもしれないから。

└

sudoでechoを使って、非sudoシェルからリダイレクトすることはできないよ。echo 3 | sudo tee /proc/sys/vm/drop_caches か、sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' だね。それと、/procのタイプミスも直したよ。

禁輸が破られた理由が気になるな。漏れたのか、それとも第三者が独自に見つけたのか？

└

無関係な第三者によって公開されました。

これはCopy Failと根本原因や悪用の仕方が非常に似ています。LLMに頼りすぎると失われるものがあることを示しています。それは探求です。AIを使って脆弱性研究を行うと、創造性が妨げられると感じます。質問をしてすぐに答えを得るだけのワークフローだと、周りに何があるかを見ることができません。まるで魔法のランプの精のように、求めたものだけが得られて、他には何もありません。Copy Failを発見した研究者は、何かおかしいと気づいてからAIに依存していました。もし彼が自分でたくさんのコードを手動で調べていたら、これらの双子のバグを見つけるチャンスがもっとあったでしょう。同時に、少しでも方向性の少ないプロンプトを使えば、最前線のLLMも彼のためにこれらのバグを見つけていたと思います。これは一緒に作業することでパフォーマンスが悪化する、非常に珍しいネガティブシナジーのケースです。

└

いや、私の読み違いでなければ、同じ根本原因だよ：IPsecの拡張ESNの高32ビット == authencesnモジュール/暗号モード。copy.failのために間違ったものが修正されたのは、みんながAF_ALGを責めたから。 [注: はい、同じauthencesnの問題です。https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... コード内にはauthencesnとは書かれていませんが、コメントにはあります。それでも同じ問題です。] [注2: RxRPCの問題は別です。これはESPのことです。]

└

これらはすべてページキャッシュポイズニング攻撃（dirtyfrag、copyfail、dirtypipe）です。SUIDバイナリに対して、ページキャッシュに防御策を講じるべきでは？

└

よくわからないな。LLMが最初にこれらのバグを見つけたんだよね。君は、これらの発見が脆弱性発見には悪影響だって言ってるように聞こえるけど。

└

それか、続きのプロンプトとして「似たようなバグを見つけて」ってのもあるね。実際のケースが提示されれば、似たようなバグを見つけるのはそんなに難しくないよ。クリエイティビティの部分については同意するけど。どんなツールでもそうだけど、AIは盲点を作ることがあるからね。完全にワークフローを奪われずに補助的に使うのは難しいよ。

└

あなたのワークフローが質問してすぐに答えを得ることだけで構成されていると、周りが見えなくなる。だから、外に出て、時間を使って散歩したり、公園に行ったり、ベンチに座って鳥の声を聞いたり、目を閉じてリラックスすることがすごく大事なんだ。今の状態は実際には素晴らしい。

└

AIが発見した別のルート脆弱性と似ているが、同じではない脆弱性を見つけるのは非常に難しい。AIが十分に探索しているという反事実はあるのかな？両方の脆弱性が一つにまとめられている以外で。

もう一度聞くけど、なんでalgif_aeadがcopy.failのことでこんなに叩かれてるの？authencesnがバカなんだよ。authencesnは修正されてないし。その結果が今出てきたけど、同じ（たぶん）境界外書き込みにプレーンなネットワークソケットを通じてアクセスできることが分かった。これを思いついていたらよかったけど、思いつかなかった。 [注: ESP経由の問題を指しています。RxRPCの方は全く関係ないと思います。]

つまり、私が正しく理解しているなら、3つのモジュールが関与しているということですね：

esp4（カーネル設定「CONFIG_AF_RXRPC」）
esp6（カーネル設定「CONFIG_INET_ESP」）
rxrpc（カーネル設定「CONFIG_INET6_ESP」）これで合っていますか？

└

名前と設定オプションを混同してるけど、そうだね、その3つのオプションを無効にすれば「安全」になるはず。ただし、保証はないよ。

誰かがユニバーサルなLinux特権昇格を見つけるたびに、どこかのシステム管理者が「だからこそ、rootで実行しないんだ」とつぶやきながら、自分のコンテナが本当に隔離されているかを神経質に確認しているんだよね。

└

だから私たちはルートで動かないんだ。全てのポイントは、ルートに昇格できるってことだよ。

└

この攻撃クラスでは、任意のユーザーからUID 0に昇格できる。ルートで動かないからといって助かるわけじゃない。実際、この攻撃はルートで動いていないプロセス向けなんだ。ただし、UID 0がシステム全体の権限にマッピングされないユーザーネームスペースにいる場合や、setuidバイナリのページキャッシュを共有していない場合、この攻撃はLPEにはつながらない。

誰か、Debianが脆弱かどうか知ってる？ Debian 12とDebian 13のマシンでそのエクスプロイトを試したけど、自分では再現できなかったんだ。

└

新しいDebian 13のドロップレットでデジタルオーシャン上でエクスプロイトを試してみたけど、うまくいったよ。

└

Debian 13（Trixie）でkernel 6.12.57+deb13-amd64を使ってこの問題を再現できたけど、Debian 12（Bookworm）でkernel 6.1.0-42-amd64では再現できなかった。BookwormのDebianパッケージのセキュリティストリームにいない人には、kernel 6.1.0-42-amd64は実際にはcopy.failに対して免疫がある。dirtyfragにも免疫があるようで驚きだね。もしまだセキュリティストリームでパッチを当てていないなら、コミット2b8bbc64b5c2を保持している任意のカーネルバージョンを選べるよ。同じコミットが偶然にも特定のDebian 12のカーネルバージョンをdirtyfragから守っているかもしれないと思ってる。

もしこれが主要なディストリビューション全てで機能するなら、メンテナがどれだけ無責任かに驚かされるばかりだよ。ユーザーの0.1%にも満たない人にとって便利だろうと思われるオプションのカーネル機能が、デフォルトで有効になってるって…なんで？これは1999年のLinuxディストリビューションが、インターネットに接続された多数のネットワークサービスをデフォルトでインストールしていた頃のやり方に似てる。でも、もう1999年じゃないんだよ。

└

...でもデフォルトで有効になってるの？なんで？XZがSSHにリンクされてる理由も気になるけど…でもsystemdが有効なディストロだけだし（結構多いけど）。ただ…なんで？それから、悪意じゃなくて無能さを指摘して、「確かにsystemdディストロにしか影響しないけど、これはsystemdとは全然関係ない」とか言うのはおかしいよね。私が見たのはsystemdのバックドア（ごめん、エクスプロイト）だけだった。で、最近のcopy.failについてだけど、全てのメンテナーが無責任ってわけじゃない。中には、自分たちのディストロで事前に取ったセキュリティ対策のおかげで脆弱性がないって自慢してる人もいるし。だけど、確かにこれは狂ってるよね。なんでだろう。Ubuntuは本当にひどい。まるで「yes | ..」で全てのモジュールをカーネルに直接インクルードするような設定をしてるみたい。「私たちはセキュリティを真剣に考えてる、ほら、IPsecのバックドア（ごめん、エクスプロイト）モジュールがカーネルに直接入ってるよ」。「IPsecには'sec'が含まれてるから、私たちはバックドア（ごめん、安全）だよ」。

もし必要ないなら（ルートレスコンテナ）、特権のないusernsを無効にしてこの2つをブロックできるよ：echo 1 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns ただし、サンドボックス（例えばブラウザ）が壊れるかもしれないけどね。

ハクソク