本文へ
ハクソク

世界を動かす技術を、日本語で。

Dirtyfrag: ユニバーサルLinux LPE

元記事: 原文(openwall.com)

概要

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

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

  • Dirty Frag は、全主要Linuxディストリビューションに影響する ローカル特権昇格（LPE）脆弱性。
  • 過去の Copy Fail 脆弱性と同等の深刻な影響。
  • 2つの未修正脆弱性 を組み合わせて利用する手法。
  • パッチ未公開、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の情報に継続的な注意 が必要。

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

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が十分に探索しているという反事実はあるのかな？両方の脆弱性が一つにまとめられている以外で。

Hacker Newsで議論の続きを見る

同じ出典の記事