esp4 esp6 rxrpc を無効化する方法が示されているLinuxのセキュリティ界隈で、またかなり嫌なニュースが出てきました。
oss-security に投稿された「Dirty Frag: Universal Linux LPE」は、ざっくり言うと「多くのLinux環境でroot権限まで上がれてしまうかもしれない」という話です。
ここでの LPE は Local Privilege Escalation の略で、直訳すると「ローカル権限昇格」です。
つまり、もともとは普通のユーザー権限しか持っていない攻撃者が、システム管理者と同じ root 権限を奪えてしまう、という意味です。rootはLinuxの“全権管理者”なので、ここまで行かれるとかなりまずいです。個人的には、これ系の脆弱性は「サーバーの中に入られたあと」の被害を一気に最大化するので、かなり厄介だと思います。
投稿者の Hyunwoo Kim 氏によると、Dirty Frag は 「universal LPE」、つまり「汎用的に使える権限昇格」だとされています。
しかも、その影響は主要なLinuxディストリビューションすべてに及ぶ、とかなり強い言い方がされています。
そして重要なのが、Dirty Frag は単独のバグ1個ではなく、2つの脆弱性を連鎖させるという点です。
投稿では、次の2つが挙げられています。
つまり、片方だけでは足りず、2段構えで悪用するタイプです。こういう攻撃は、個々のバグがそこまで派手に見えなくても、つながった瞬間に一気に危険度が跳ね上がるのが怖いところです。
本文では、この脆弱性は以前の Copy Fail と似たインパクトを持つと説明されています。
Copy Fail の詳細を知らなくても、ここで重要なのは「前例のある、かなり深刻な root 取得級の問題として扱われている」という点です。
セキュリティ報告で「前のあれと同じくらい危ない」と言われると、だいたい空気が一段重くなります。
これは大げさではなく、運用現場では「すぐに調査」「影響範囲の確認」「一時回避策の適用」が必要になるレベルです。
この件でさらにややこしいのは、embargo が破られたと明言されていることです。
embargo というのは、脆弱性の詳細や修正を公開前に関係者だけで調整し、パッチを用意してから発表するための「公開待機期間」のようなものです。
ところが今回は、そのスケジュールが崩れたため、
というかなり困った状態になっています。
これは運用する側からすると最悪寄りです。
なぜなら、普通は「発見→修正→公開」の順番で心の準備ができるのに、今回は先に危険情報だけが出る形だからです。もちろん、深刻性を広く伝える意味では公開も重要ですが、現場目線では「じゃあどう守るの？」となります。
投稿には、とりあえず問題のあるモジュールを無効化するコマンドが載っています。
対象は以下のモジュールです。
esp4esp6rxrpcそして、/etc/modprobe.d/dirtyfrag.conf に install ... /bin/false を書き込み、該当モジュールをロードできないようにする、という回避策が示されています。
この方法は、ざっくり言えば「その機能を使わせない」というものです。
ただし、こういう対処は便利な反面、当然ながらその機能に依存している環境では副作用が出るかもしれません。なので、実運用では「とりあえず全部止める」で終わらず、サービスへの影響を確認しながら進める必要があります。
個人的には、こういう回避策が最初に提示されるのはありがたい一方で、「本修正版がないのに止血だけ先にしないといけない」という、現場の胃が痛くなる感じがすごいなと思います。
投稿には、かなり長い exploit code も含まれています。
ここまで露骨にコードが出ると、脆弱性の深刻さが一段リアルになります。
コードを細かく追う必要はありませんが、雰囲気としては次のことをしているように見えます。
unshare() を使って user namespace と network namespace を作るnetlink で XFRM 関連の設定を行うUDP_ENCAP や ESP まわりの処理を使って、問題のある挙動を引き起こすshell_elf を書き込むuser namespace
ユーザー権限を「閉じ込めた小さな世界」のように扱う仕組みです。
一見安全そうですが、ここが攻撃の足場になることがあります。
network namespace
ネットワーク設定を別世界に分ける仕組みです。
コンテナ技術でもよく使われます。
netlink
ユーザー空間のプログラムが、Linuxカーネルと直接やり取りするための通信手段です。
ネットワーク設定やルーティング、各種セキュリティ機能の操作に使われます。
こうした仕組みは本来、柔軟で便利です。
でも便利な仕組みほど、バグがあると「攻撃の踏み台」になりやすい。Linuxカーネルの脆弱性が面倒なのは、まさにここだと思います。
この Dirty Frag の件で重要なのは、単に「危ない脆弱性が出た」という話だけではありません。
「主要ディストリビューション全般」と言われると、個別製品の穴では済まない話です。
サーバー、VM、コンテナ基盤、開発環境など、Linuxを使う場所はとにかく広いので、影響範囲の見極めが難しくなります。
権限昇格の怖さは、被害が一気に“別次元”になることです。
ファイルの読み書き、サービス改ざん、認証情報の窃取、永続化など、できることが一気に増えます。
今回は embargo が破られ、修正やCVEがまだ整っていない状態で情報が出ています。
防御側からすると、これが本当にしんどい。
「危ない」とは分かったけれど「どう直すか」がまだ十分ではない、というのは最悪のシナリオの一つです。
一般ユーザーにとっては、まずは慌てすぎないことが大事です。
ただし、Linuxサーバーやインフラを運用している人は、かなり真面目に続報を追うべき案件だと思います。
特に気にしたいのは次のあたりです。
esp4 esp6 rxrpc の利用状況Linuxの脆弱性は、発表された瞬間よりも、その後に各社・各コミュニティがどう修正版やワークアラウンドを出すかで実害が決まることが多いです。なので、今回も「速報を見たら終わり」ではなく、運用側の対応スピードが勝負になるでしょう。
Dirty Frag は、Linuxで広く影響しうる root 権限昇格の脆弱性として公開されました。
しかも、単体の穴ではなく、2つの脆弱性を組み合わせた攻撃だと説明されています。
embargo が破られたため、現時点ではパッチやCVEが揃っておらず、まずはモジュール無効化などの回避策が示されている段階です。
こういう話を読むたびに思うのですが、Linuxカーネルのセキュリティは本当に“巨大で繊細な機械”だなと思います。
便利で強力だからこそ、1か所のほころびが全体の信頼を揺らす。Dirty Frag は、その怖さをかなりわかりやすく見せている事例ではないでしょうか。