Dirty Frag: 汎用Linux LPE（ローカル権限昇格）脆弱性

(openwall.com)

2 ポイント投稿者 GN⁺ 2 시간 전 | 2件のコメント | WhatsAppで共有

Dirty Frag は、主要なLinuxディストリビューション全体で root 権限の取得を可能にする汎用ローカル権限昇格脆弱性であり、責任ある公開スケジュールとエンバーゴが破られたため、パッチもCVEもまだ存在しない
Dirty Pipe、Copy Fail といったバグクラスの拡張であり、決定論的なロジックバグであるためレースコンディションが不要で、成功率が非常に高い
脆弱性の有効期間は約 9年で、Ubuntu、RHEL、Fedora、openSUSE など主要ディストリビューションでテスト済み
既存の Copy Fail 緩和策（algif_aead ブラックリスト）を適用したシステムでも、依然として Dirty Frag に対して脆弱
暫定的な緩和策として、各ディストリビューションのパッチが出るまで、脆弱性が発生する esp4、esp6、rxrpc モジュールの削除を推奨

概要

sk_buff 構造体の frag メンバーを汚染するバグクラスで、Dirty Pipe と Copy Fail が属する同一バグクラスの拡張
xfrm-ESP Page-Cache Write 脆弱性と RxRPC Page-Cache Write 脆弱性をチェーンすることで、主要なLinuxディストリビューションで root 権限を取得可能
決定論的なロジックバグであり、タイミングウィンドウに依存せず、レースコンディションも不要
エクスプロイトが失敗しても カーネルパニックは発生せず、成功率が非常に高い

2つの脆弱性をチェーンした理由

xfrm-ESP Page-Cache Write は Copy Fail に似た強力な 任意の4バイト STORE プリミティブ を提供し、ほとんどのディストリビューションに含まれているが、名前空間作成権限が必要
Ubuntu では AppArmor ポリシー により非特権ユーザの名前空間作成がブロックされる場合があり、この環境では xfrm-ESP Page-Cache Write をトリガーできない
RxRPC Page-Cache Write は名前空間作成権限が不要だが、rxrpc.ko モジュール自体がほとんどのディストリビューションに含まれていない
- ただし Ubuntu では rxrpc.ko モジュールが デフォルトでロード される
2つの脆弱性をチェーンすることで、それぞれの 弱点を相互補完 し、すべての主要ディストリビューションで root 権限を取得可能

Copy Fail との関係

Copy Fail がこの研究を始める動機だった
xfrm-ESP Page-Cache Write は Copy Fail と 同じシンク（sink） を共有するが、algif_aead モジュールの可用性に関係なくトリガー可能
公開されている Copy Fail 緩和策（algif_aead ブラックリスト）を適用したシステムでも、Dirty Frag に対して依然として脆弱

影響範囲

xfrm-ESP Page-Cache Write: コミット cac2661c53f3（2017-01-17）から upstream まで
RxRPC Page-Cache Write: コミット 2dc334f1a63a（2023-06）から upstream まで
脆弱性の 有効期間は約9年
テスト済みのディストリビューションバージョン:
- Ubuntu 24.04.4: 6.17.0-23-generic
- RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
- openSUSE Tumbleweed: 7.0.2-1-default
- CentOS Stream 10: 6.12.0-224.el10.x86_64
- AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
- Fedora 44: 6.19.14-300.fc44.x86_64

緩和策

責任ある公開スケジュールとエンバーゴが破られたため、どのディストリビューションにもパッチは存在しない
暫定的な緩和策として、脆弱性が発生するモジュールを削除するコマンドを提供:
```
sh -c &quot;printf &#039;install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n&#039; &gt; /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2&gt;/dev/null; true&quot;  
```
- esp4、esp6、rxrpc モジュールを /etc/modprobe.d/dirtyfrag.conf に ブラックリスト登録 してアンロードする
各ディストリビューションがパッチをバックポートした後、その更新を適用する必要がある

公開経緯

linux-distros@vs.openwall.org のメンテナーらと協議した後、彼らの要請に従って Dirty Frag 文書を公開
エンバーゴは 外部要因によって破られた状態 であり、現時点でパッチや CVE は存在しない
PoC は linux-distros との協議を経て、正確な情報提供を目的として 公開されており、許可されていないシステムでの使用は禁止

2件のコメント

GN⁺ 1 시간 전

Hacker News の意見

これは根本原因と悪用方法が Copy Fail と非常によく似ている
LLM に作業を多く任せると失いやすいもの、つまり探索をよく示している事例だと思う。AI で脆弱性研究をすると創造性がかなり阻害される感じがする。質問すればすぐ答えが返ってくる流れでは、周囲に何があるのか見えなくなる。ジーニーのように正確に頼んだものだけを出して、それ以上はない
Copy Fail を見つけた研究者は怪しい点を見たあと AI に大きく依存していたが、自分で大量のコードを掘っていたら、こうした双子のバグを見つける機会はもっと多かったはずだ。同時に、プロンプトをもう少し非指示的にしていたら、最新の LLM でもこれらのバグを見つけられた気がする。一緒に作業したのに性能が落ちた、かなり珍しい 負のシナジー の例だ
- 読み間違いでなければ、似ているのではなく 同じ根本原因 だ。IPsec の Extended ESN 上位 32 ビット == authencesn モジュール/暗号モードの問題だ
  copy.fail では見当違いな部分が修正され、人々は性急に AF_ALG のせいにした
  [編集: そう、同じ authencesn の問題だ。https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... のコードでは authencesn はコメントにしか出てこないが、それでも同じ問題だ]
  [編集2: RxRPC の問題は別で、ここでは ESP 側の話をしている]
- 後続のプロンプトで「似た種類のバグを探して」と頼むこともできる。実際の事例が整理されたあとなら、似たバグを探すのはそれほど難しくない
  創造性の話は理解できる。どんなツールでも AI は 視野を狭める ことがある。ワークフローを完全に任せず補助としてだけ使うのは難しい
- 理解できない。そもそもこれらのバグを見つけたのは LLM だ。なのに、その発見をもって脆弱性発見に LLM は悪いというシグナルだと言っているように見える
- 根拠のある話なのか、それともただ即興で語っているだけなのか気になる
- AI が見つけたものに似てはいるが完全に同一ではない根本脆弱性をもって、AI は探索できないという教訓と見るのはかなり難しい
  2つの脆弱性がまとめて公開される場合以外で、どんな反実仮想の状況なら「十分に探索できた」と言えるのか気になる
「エンバーゴが破られたため、これらの脆弱性に対するパッチや CVE はない」
リンク: https://github.com/V4bel/dirtyfrag
詳しい分析: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
重要なのはここだ: 「Copy Fail はこの研究を始める動機だった。特に Dirty Frag 脆弱性チェーンの xfrm-ESP Page-Cache Write は Copy Fail と同じ sink を共有している。しかし 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 echo 3 > /prox/sys/vm/drop_caches では sudo は効かない。sudo が実行するのは echo だけで、実際の書き込みはしないからだ
  それに、マシンがすでに悪用されているなら、その程度では手遅れだ。ディスク上のあらゆるものが破損している可能性があるので、ディスクイメージ全体を作り直すべきだ
- 非 sudo シェルで sudo echo とリダイレクトをあのように使うことはできない
  echo 3 | sudo tee /proc/sys/vm/drop_caches
  または
  sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
  それと /proc のタイプミスも直した
- 参考までに、echo 1 > ... でも緩和できる。全部を消す必要はなく、1 で ページキャッシュ だけ消せば十分だ
  Ubuntu 26.04 でローカルテストしたところ、エクスプロイトを実行して root を取得し、緩和策を設定したうえで引数なしで su を再実行すると即座にパスワードなしで root になった。その後ページキャッシュを消すと、su はパスワードを要求した
ホワイトリストにある カーネルモジュール だけがロードされることを保証する簡単な方法が必要だ。必要もないモジュールを延々とブラックリストに入れるのにはうんざりしている
もう一度聞くが、なぜ copy.fail で algif_aead が全部悪者扱いされるんだ？愚かなのは authencesn だ
authencesn は修正されず、その結果が今出てきた。普通のネットワークソケット経由で同じ、たぶん同じ 範囲外書き込み に到達できることが示された
これを思いつければよかったが、できなかった
[編集: ESP 経由の問題について言っている。RxRPC の問題は、私の理解では完全に別物だ]
これが本当に主要ディストリビューション全部で動くなら、メンテナたちがどれほど無責任か改めて驚かされる。ユーザーのたぶん 0.1% 未満 にしか有用でない任意のカーネル機能がデフォルトで有効になっているなんて、なぜなんだ？
1999 年の Linux ディストリビューションが、インターネットに露出するネットワークサービスを何十個もデフォルトインストールに入れて配布していた慣行を思い出す。だが今は 1999 年ではない
- ディストリビューションのメンテナが「君には不要だろう（YAGNI）」と判断して特定の機能をブラックリストに入れるのは、かなり大きな要求だ。誰が何を使うかは分からないからだ。ユーザーが戻ってきて本当に欲しいものに合わせてビルドを調整するのはいつでもできる
  昔の Linux 初期に make menuconfig を回して、カーネルに欲しい機能だけを正確に選んでいた時代を思い出す。正直、あの時代に戻りたいとは思わない
  ただ、ここで簡単に改善できそうなのは RHEL だ。RHEL は多くのモジュールをロード可能モジュールにせずカーネルに直接コンパイルしているため、copy fail のような緩和策が使えなかった。そういうものを少し減らせるのではないかと思う
- ユーザーが使わなさそうなコンポーネントを無効化しつつ、システムの利用を極端に難しくしない方法はない。この間抜けな OS を 25 年使っている私ですら、何かをしたいときに何を有効化・無効化すべきか知る方法がない
  Linux ディストリビューションのメンテナは地球上で最も責任感のあるソフトウェアメンテナたちだ。セキュリティ慣行は愚かなプログラミング言語のパッケージマネージャよりずっとましで、選別されたパッケージ一覧を維持し、変更をレビューし、バグを修正し、複雑なパッケージング問題を解決し、修正をバックポートし、段階的リリースを使い、世界中のミラーへファイルを配布し、すべてのファイルを暗号学的に検証している。しかもこれをすべて無償でやっていることも忘れてはいけない
- デフォルトで有効なのではない。必要時にロードされる 任意モジュール だ。カーネル全体の設計として、ユーザーに必要な中核機能はコンパイル済みにし、それ以外のほぼすべては必要に応じてロードされるモジュールとして提供するようになっている
- 多くの意味で、モバイルではないコンピュータは今なお 1999 年にとどまっている。Android ははるかに新しく、スタック全体に強制アクセス制御を統合する機会があったため、他の Linux システムよりはるかに安全だ
- これを悪用するにはコンピュータに直接アクセスできなければならない。悪意ある USB デバイスや、サプライチェーン攻撃、あるいはユーザーが喜んでまたは自動的にインストールする既知のソフトウェアを悪用する形になる。さらに言えば、事実上任意のターミナルコマンドを実行できる必要があり、そのソフトウェアの隔離においてすでに重大な侵害だ
  攻撃者がそこまでやれているなら、すでに状況は悪い。そこから root へ権限昇格することは、その時点では懸念事項の中でも小さい部類だ
  下で別の人が貼っているように https://xkcd.com/1200/
  人々が怖がる前に、この脆弱性が実際に何なのか理解すべきだ
長い年月を経て、ついに「目が十分に多ければ、すべてのバグは浅い」という状態になったが、あまりうれしくない。これからは週に何度も カーネル更新 をしなければならないのだろうか？
- 誰かが家に侵入して、どうにかしてデフォルトの認証情報を見つけ出し、さらに root アクセスまで得ると思っているのか？
エンバーゴがどう破られたのか気になる。リークだったのか、それとも第三者が独自に見つけたのか？
- そもそも エンバーゴ は存在しないし、存在しえない
  Linux はオープンソースなので、セキュリティバグを修正するすべてのパッチは即座に全員に見える。カーネル開発のやり方上、これを回避する方法はない。人々が言う「エンバーゴ」とは、パッチ説明に「THIS IS A LPE」と露骨に書かず口をつぐんでいれば、メーリングリストに「公式」メッセージが出るまで脆弱性が漏れていないふりができる、というかなり間抜けな発想だ
  昔ならこのアプローチもある程度は擁護できたかもしれないが、LLM の時代には、メーリングリストの diff を自動パイプラインで最新モデルに流し込み、セキュリティ問題を修正したパッチかどうか識別させられるので、愚かであるだけでなく危険でもある
- パッチへのリンクが誰かの X アカウントに投稿され、それを見た別の人が 1 時間もたたずに動くエクスプロイトを公開した。LLM で悪用した可能性はあるが、速い切り替え時間以外に立証された主張ではない
  https://x.com/encrypted_past/status/2052409822998392962
- 無関係な第三者が公開で投稿した
Debian が脆弱か知っている人はいる？ Debian 12 と Debian 13 のマシンでエクスプロイトを試したが、自分では再現できなかった
- Debian 13、つまり Trixie の 6.12.57+deb13-amd64 カーネルでは再現したが、Debian 12 Bookworm の 6.1.0-42-amd64 カーネルでは再現できなかった
  Bookworm で Debian パッケージのセキュリティストリームを使っていない人にとっては、6.1.0-42-amd64 カーネルは実際に copy.fail に耐性がある。dirtyfrag にも耐性があるように見えるのは驚きだ。セキュリティストリームでまだパッチしていないなら、commit 2b8bbc64b5c2 を保持したカーネルバージョンを選べる。一部の Debian 12 カーネルバージョンが同じコミットによって dirtyfrag から偶然守られているのかもしれないと思う
- DigitalOcean の新しい Debian 13 droplet で今しがたエクスプロイトを試したが、動いた
- 完全に最新状態の Debian 13 でテストし、エクスプロイトが動作することを確認した。緩和策も動作することを確認した
ubuntu:latest コンテナで新しいデフォルトユーザーとして実行した
git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
結果: dirtyfrag: failed (rc=3)
良い知らせだ！
- コンテナ内で実行したときは同じ結果だったが、ホストで直接実行するとシェルを得られた。これはエクスプロイトがコンテナ内では動かないことを示しているだけだ。したがって、コンテナが脆弱でないか、スクリプトがコンテナで動くよう調整が必要なのかもしれない
  copy fail はコンテナ脱出に使えるので（https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...）、エクスプロイトには少しの変更だけで済むだろうと推測する
- コンテナをこのテストの信頼できるプラットフォームと見るのは難しい。正常なものでもそうでなくても、コンテナでは失敗するものが多い

GN⁺ 2 시간 전

Lobste.rsの意見

Linuxサーバーを共有で運用する身としては、実に大変な一週間だった。それでも今回の公開は要点をすぐに示してくれてよかった
ただ、緩和策の案内でみんながなぜ stderr を隠しているのかは分からない
修正: これは copy.fail から「着想」を得て4月30日に報告されたとのことなので、1日も経たずに見つかったということか。印象的だ
かなり大きな共有サーバーで sudo 権限を持つ立場としては、できるだけ少ないモジュールだけを含めてカーネルを自前でコンパイルするのが良い考えなのかも気になる。長所と短所を深く検討したわけではないが、今週の2件のローカル権限昇格脆弱性はどちらも回避できたかもしれない
修正2:
```
 * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.  
```
おお、これは setuid が不要なのか。含めてくれて助かる
- 私が管理しているマルチユーザーシステムでもそうしていて、今週のローカル root エクスプロイト2件を実際に回避できた
稼働中のシステムでロードされているカーネルモジュール一覧を取得して、そのシステムの modprobe 許可リストとして設定するのは、可能で現実的だろうか?
CopyFail と DirtyFrag はどちらも、私が確認したどのシステムでもロードされていないカーネルモジュールを悪用しているように見えた。だとすれば、明らかに不要なモジュールをブロックしておけば、いくつかの攻撃を事前に緩和できるのではないか?
2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
こういうことがどうして許されるのか分からない。これほどの規模の情報が、そんな信頼しがたい環境に置かれていること自体、本当にあり得ないと感じる
- ここで言う「無関係な第三者が公開した」がこの件を指すのかは分からないが、参考までに Brad Spengler は修正コミットが先に上がったのを見て、コミットメッセージが示唆するセキュリティ脆弱性に気づき、返信で誰かがバイブコーディングでエクスプロイトを作っていた
  Linux のコミットを監視している第三者なら、誰でも同じ手がかりを拾ってエクスプロイトを作れた可能性がある
- 「無関係な第三者」という表現は、そのバグがエンバargo中だと知らなかった、という意味にも聞こえる
  ここでの「信頼しがたい環境」はインターネット全体のことで、実質的に隔離と呼べるものはほとんどない。もともとそうだったが、今はそれがより明確になっただけだ。Apache httpd のバグが修正前に2回も再発見されたという Stefan Eissing の最近の投稿も参考になる
影響を受けるモジュールが本当にロード不能になっているかをテストする方法はあるだろうか?
CopyFail のとき、最初の緩和策適用時にミスをしていた。/etc/modprobe.d/ 内のファイル名が .conf で終わっていなかったのだが、https://news.ycombinator.com/item?id=47954159 のテストコマンドを実行するまで気づかなかった。esp4/esp6/rxrpc モジュールにも同様のコマンドはあるだろうか?
- 3つのモジュールすべてを modprobe でロードしてみたところ、前回と同じエラーが出た
  添付の概念実証コードもあるが、まだ試してはいない

Dirty Frag: 汎用Linux LPE（ローカル権限昇格）脆弱性

概要

2つの脆弱性をチェーンした理由

Copy Fail との関係

影響範囲

緩和策

公開経緯

関連記事

2件のコメント

Hacker News の意見

Lobste.rsの意見