新しいLinuxのudisksの脆弱性により、攻撃者が主要なLinuxディストリビューションでroot権限を取得可能に

339日前原文(bleepingcomputer.com)

概要

Linux主要ディストリビューション に影響する2つの ローカル権限昇格脆弱性 が発見
openSUSE Leap 15 および SUSE Linux Enterprise 15 のPAM設定ミスと libblockdev/udisks の不備
Qualys TRU が脆弱性を発見し、PoCで複数ディストリへの攻撃に成功
管理者に早急なパッチ適用 が強く推奨
自動パッチ管理 の重要性と最新動向

Linuxディストリビューションにおける新たなLPE脆弱性

CVE-2025-6018 ：openSUSE Leap 15およびSUSE Linux Enterprise 15の PAM設定ミス
- ローカル攻撃者が「allow_active」ユーザー権限を奪取可能
CVE-2025-6019 ： libblockdev の脆弱性
- 「allow_active」ユーザーが udisksデーモン 経由で root権限 取得可能
- udisksはほぼすべてのLinuxディストリでデフォルト稼働
2つの脆弱性を 連鎖利用 することで、攻撃者は 短時間でroot権限奪取 ・システム完全制御
libblockdev/udisks 単体でも非常に危険
Qualys TRU による実証攻撃：Ubuntu、Debian、Fedora、openSUSE Leap 15で root権限取得 に成功

脆弱性の影響範囲と対策

udisksの普及により、 ほぼ全てのLinuxシステムが影響対象
「allow_active」権限取得手法が存在し、 PAM設定ミス が更なるリスク増大
root権限取得 によるエージェント改ざん・永続化・横展開の危険性
未パッチサーバ1台 が全体のセキュリティを脅かす要因
PAMとlibblockdev/udisksの両方を即時パッチ適用 が必須
詳細技術情報と パッチリンク はOpenwallの投稿参照

過去のLinux関連重大脆弱性

Polkitのpkexec（PwnKit）
glibcのld.so（Looney Tunables）
Kernelのファイルシステム層（Sequoia）
Sudo Unixプログラム（Baron Samedit）
needrestartユーティリティ に10年以上前から存在したLPE脆弱性
- Ubuntu Linux 21.04以降でデフォルト利用
Looney Tunables公開後、 PoCエクスプロイトが即座に公開
- 1ヶ月後、 Kinsingマルウェア によるCSP認証情報窃取攻撃が発生

パッチ管理の自動化と現代IT運用

従来のパッチ管理 ：複雑なスクリプト・長時間作業・突発対応の連続
現代のIT組織 ：自動化で 迅速なパッチ適用 ・運用負荷軽減・戦略的業務への集中
Tinesの新ガイド ：パッチ適用の自動化手法、スクリプト不要の運用効率化を解説
全組織にとって必須のセキュリティ対策

Hackerたちの意見

20年以上もデスクトップでLinuxを快適に使っている者として言わせてもらうと、機能面でもセキュリティ面でも、Linuxは永遠の実験だと思う。

└

Linuxが実験だと思ってるなら、他のOSも見てみるべきだよ。

└

確かに面白い視点だね。私もプライベートと仕事で両方使ってるけど、セキュリティ面では（SELinuxがあっても）物足りない感じがする。でも機能面では、Windowsよりも遥かに優れてると思う。ただ、ゲーム体験だけは別だけどね。デスクトップにGrapheneOSみたいなのがあればいいのに（Qubesのことは知ってるけど）。

└

20年前、Windowsはみんなにroot権限を与えてたの？

└

特に実験的に感じるのは、コンテナ技術だね。

└

Re:"永遠の実験"... Windows 11見たことある？それとも10？開発者たちは手を離せなくて、数ヶ月ごとにあれこれ変更したり、壊したり、修正したりしてるよね。

└

ソフトウェアはほとんど「完成」することがないから、自然と常に進化する実験みたいなもんだよね。

└

これって、実際にはすべての（アクティブな）ソフトウェアに当てはまる。そうじゃないと、人々はそれを古くなったとか放棄されたって呼ぶから。

└

ここで話してるのはローカル特権昇格のことね。つまり、1) 攻撃者がすでにシステムにアカウントを持っていること、2) アプリudisksがシステムにインストールされていることが前提。みんな同じ戦いをしてるし、それはいいことだよね。最近はシステム全体が攻撃しづらくなってるから、こういうことが起きてる。これはすべての主要なOSに当てはまる。ファンボーイだけが現実を曲げて、これを善対悪の議論にしようとするんだよね。

└

他のOSが完璧だなんて思わない方がいいよ。マイクロソフトは常にパッチを当ててるし、アップルは多くのハッキングの原因になってて、何千人ものVIPが影響を受けたり、殺人事件も起きてるからね。

2週間前に修正されたよ（少なくともDebianでは）。

└

そうだね。Gentooでは全く問題なかった。

かなり古い問題で、openSUSEだけに影響がある。タイトルはすごく誤解を招くね。

└

Qualysの脅威調査ユニット（TRU）がこの2つの脆弱性を発見して報告したんだけど、証明概念のエクスプロイトも開発して、CVE-2025-6019をターゲットにしてUbuntu、Debian、Fedora、openSUSE Leap 15のシステムでルート権限を取得することに成功したんだ。 https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt

└

openSUSE Leap 15（現行LTS） - SUSE Linux Enterprise 15（現行LTS） - Debian 12（現行LTS） - Ubuntu 24.04（現行LTS）… 他のバグのこと考えてたの？

udisksは依存関係を除くと、265,334行のコードがあるんだ。対照的に、pmountは19,978行で、13倍以上少ない。sudoは、たくさんのポリシーコードがあるsetuidバイナリで、210のCVE / 430,150 kLoC = 約0.5 CVE/kLoC。57.5%のCVEはCVSSが7以上だから、0.5 * 0.575 = 0.2875 CVE7/kLoC。ざっくり計算すると、udisks: 0.2875 CVE7/kLoC * 265,334 kLoC = 約76.28のクリティカルCVE; pmount: 0.2875 CVE7/kLoC * 19,978 kLoC = 約5.7のCVE。

└

sudoがあんなに行数あるなんて信じられないよ。OSに何かを制限なしで実行させるだけだと思ってたのに、自分でロジックを持ってるなんて。

└

210のsudoのCVEリストが見つからないんだけど、これって本当に正しいの？

└

UbuntuがsudoのRust実装に切り替えるみたいだね。https://www.phoronix.com/news/Ubuntu-25.10-sudo-rs デフォルトリポジトリはこちら: https://github.com/trifectatechfoundation/sudo-rs 残念ながら、許可されたライセンスなんだ。なんでだろう？ライブラリじゃないのに。でも、長期的にはセキュリティが改善されるはずだね。

ローカル特権昇格、気にしない。もし誰かが共有カーネルでどこかにセキュリティ境界を引けると思ってるなら、カーネルのCVEデータベースを見てみるべきだよ（そして驚愕するはず）。派手なタイトルのエクスプロイトがある一方で、聞いたこともないようなものが20個もある。プログラムを慎重に構造化してシステムコールの使用を制限し、最小限でよく監査されたシステムコールフィルタリングレイヤーを使えば、カーネルの大部分を隠すことはできるけど、本当に何をしてるかを理解してないといけないし、適切なセキュリティ強化は多くのソフトウェアを壊すことになる。基本的なセキュリティレベルを得るためには、「BPF」の文字が入ったものはすべて無効にして、/procや/sysのようなすべての仮想ファイルシステムを隠し、io_uringを無効にして、CONFIG_*を見つけたらそれを削除して、何かが動かなくなるまで続ける必要がある。いくつかのサブシステムは他よりも脆弱に見えるけど（皮肉なことにnetfilterは安定した脆弱性の源みたい）。

└

https://xkcd.com/1200/

誰かLinuxの「allow_active」権限について説明してくれない？

└

それはカーネルにとっては意味のないもので、polkitや関連するユーザーランドの認証フレームワークの概念なんだ。要するに「今、マシンの前に座ってログインしているユーザーができること」を指していて、USBドライブのマウントとか（でも任意の場所やオプションではない）を含むんだよね。

環境変数がLPEを引き起こすケースまた来たね。プロセス間で詳細を渡すのに、文字列から環境設定を解析するよりももっと堅牢な方法がいつかできるのかな。

└

IPC？

└

いや、これは環境変数じゃないよ。ツールに対する引数が間違ってるだけで、suidの部分は環境変数や環境をクリーンにすることとは関係ない。FUDを広めるのはやめてくれ。

記事の中で欠陥、バグ、セキュリティ脆弱性が混ざってるね。これは成熟した分野なのに、言葉の選び方が一貫してないと質が悪く感じる。技術的に同じ問題として扱うのは良くないよ。

└

そうは思わないな。セキュリティの脆弱性はバグの一種で、バグは欠陥の一種だよね。最も具体的な用語で問題を指摘したら、あとはあまり具体的じゃない言い方でも大丈夫だよ。そうすれば、繰り返しにならずに済むしね。（これ、うちの子供の小さい頃を思い出すな。もし「そのズボンいいね」って言ったら、「ズボンじゃなくてジーンズだよ」って返してきた。でも、もちろんジーンズはズボンの一種だし、常に具体的である必要はないんだよね。）

ああ、もう少しでSlackwareがPAMを避け続けたおかげでセキュリティホールを回避できたって自慢しようとしてたのに、2020年に導入されちゃった。 :-( 今では、いくつかのソフトウェアプロジェクトが認証にPAMに完全に依存してて、シャドーパスワードをサポートしてないみたい。なんてこった。Systemdの時みたいに、今や多くのアプリがSystemdに完全に依存してて、「フェイクSystemd」なしではLinuxデスクトップが動かない状態だよ。（例：Alpine Linuxデスクトップ、Slackwareデスクトップ）これって、企業が設計した新しいコンポーネントがシステムを乗っ取ってる感じがする。彼らはこれらのコンポーネントを色んなことができるように設計するけど、同時に強く結合して依存関係を作っちゃうんだよね（これはひどいソフトウェア設計だけど、企業製品では標準的）。その結果、もっと複雑なシステムになって、壊れやすくなってる。これらの企業が最も人気のあるLinuxディストリビューションに影響を与えてるから、彼らが急激な変更をすると、みんなそれに従わざるを得ない。まるでブラウザの世界みたいに。強力な既得権者が私たちの環境に不公平（で不健康）な影響を与えてる。20年前のディストリビューションに戻ったら、本当に必要なコンポーネントは数個だけのはずだよ：Xエコシステム（カーネルドライバー、ユーザーランドドライバー、レンダリングライブラリ）、コンソールログインプログラム、ttyマネージャー、wifiマネージャー、あとは... システムが起動した後に必要なものを考えるのが難しい。カーネルドライバーはハードウェアインターフェースの90%を占めてた。元々は、音や印刷などのためにデバイスファイルに書き込むだけでよかった。すごくシンプルなシステムで、うまく機能してた。今は、システムが動くために80個のデーモンが同時に動いてる。イベントバス、ポリシーエンジン、管理フレームワーク、数十のライブラリ、ウィンドウ環境でグラフィカルアプリを動かすための複数のコンポーネントのレイヤー。これって本当に必要なの？明らかにそうじゃない。20年前はこんなもんなしでやってたんだから。誰かがシステム設計を台無しにしたんだ。幸いにもLinuxだから、こんなものを使わされることはない。新しくてずっとシンプルなシステムでやり直すことができるし（二次システム効果を避けるように頑張るけど）。

└

devuanも偽のlibsystemdを使ってるけど、実際には壊れた呼び出しを避けるためのスタブに過ぎない。

└

BSDを再び素晴らしくしよう！

udisksは「pam_env」を通じてPAMと統合されてて、隠しファイル（例：'~/.pam_environment'）から環境変数を読み込む設計になってる。この設計は、特権昇格中でもユーザーのホームディレクトリが信頼できると仮定してる。ほとんどのディストリビューションでは、udisksはrootとして動作し、ユーザーがトリガーしたマウント/アンマウントのアクションを許可してる。この攻撃経路はpam_envの動作を監査してないけど、リスクが低いと見なされてるから。

ハクソク