Linuxでまた厄介な脆弱性が出てきました。名前は Dirty Frag。
ざっくり言うと、ローカルでアクセスできる攻撃者が、最終的にroot権限を取れてしまう 可能性がある話です。
root権限というのは、Linuxの世界では“ほぼ何でもできる管理者権限”です。
ファイルの改ざん、設定の変更、ユーザー操作の監視、バックドアの設置まで、やろうと思えばかなり広く触れてしまいます。
なので「rootを取られる」は、セキュリティ的にはかなり重いです。正直、名前が可愛い感じでも中身は全然かわいくありません。
元記事によると、Dirty Fragは Linux kernel の中にある、暗号関連のインターフェース algif_aead に約9年前から存在していたとされるローカル権限昇格の問題です。
ここでいう kernel は、Linuxの“心臓部”みたいなものです。
OSの基本動作を管理している一番大事な部分で、ここに穴があると影響が広がりやすいです。
Dirty Fragの面白い（そして嫌な）ところは、2つの別々のカーネル不具合をつなげて悪用する 点です。
記事では次の2つが使われています。
Page cache は、ざっくり言うと「ファイルの内容をメモリ上に一時保存しておいて高速に扱う仕組み」です。
そこを書き換えられると、本来触れないはずの保護されたシステムファイルをメモリ上で改変できる 可能性が出てきます。
この“ファイルを直接いじるのではなく、メモリ上でこっそり書き換える”感じが、いかにもセキュリティ研究でよく出てくる嫌なパターンです。
元記事では、Dirty Fragは Dirty Pipe や Copy Fail と同じ系統の脆弱性クラスだと説明されています。
ただし、今回は別のカーネルデータ構造の fragment field を狙う点が違うそうです。
要するに、「似たタイプの攻撃だけど、別ルートで同じようにやられる」と考えるとわかりやすいです。
攻撃者から見れば、別の裏口が増えたようなものです。
個人的には、こういう“同系統の穴が別実装にもある”話は本当に厄介だと思います。1個直して終わりではなく、設計や実装の癖まで疑わないといけないからです。
この脆弱性が怖いのは、研究者 Hyunwoo Kim 氏の説明によると、timing window に依存しない deterministic logic bug だからです。
難しい言い方ですが、簡単に言うと：
race condition は、複数の処理が同時に動くことで順番がズレて起きる問題です。
これを必要としないなら、攻撃はかなり安定しやすい。これは攻撃者にとってかなり嬉しい仕様です。いや、嬉しくては困るんですが。
記事では、少なくとも次の主要ディストリビューションが影響を受けうるとされています。
ただし重要なのは、すべてのLinux環境で即座に危険という意味ではない ことです。
コメント欄でも指摘されている通り、少なくとも「デフォルトで常に使われる脆弱性」というより、特定のモジュールが読み込まれる条件が必要 です。
元記事では、攻撃に関係するカーネルモジュールとして
esp4esp6rxrpcが挙げられています。
これらは手動で無効化する回避策が案内されていますが、当然ながら副作用があります。
特に IPsec VPN や AFS distributed network file systems が壊れる可能性があるので、やみくもに無効化すればいい話ではありません。
ここは「安全のために止めたら業務も止まった」という、よくあるが笑えないポイントです。
Hyunwoo Kim 氏は、この問題を公開し、PoC exploit も出しています。
PoC は「実際に悪用できることを示す再現コード」のことです。
研究の世界では重要ですが、攻撃者にとっても“すぐ使える材料”になり得るので、公開タイミングは非常にデリケートです。
記事によると、今回は embargo（公開猶予） が破られたため、やむを得ず公開された形です。
つまり、本来は関係者の間で先に修正を進めてから出すはずだったのに、第三者が先に出してしまったため、公開が前倒しになったという流れです。
この手の話は、研究者・ディストリビュータ・利用者の全部にとって後味が悪いです。
元記事が示している暫定対策は、次のコマンドで脆弱なモジュールを無効化する方法です。
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"
ただし、これは先ほど触れたように副作用があります。
つまり、「使えるなら無効化」ではなく、「その機能が本当に不要か確認してから」 が正解です。
こういう時、運用の現場では「とりあえず全部止める」は通りません。そこがLinux管理の難しさでもあります。
かなり深刻です。
理由は単純で、root権限の奪取は攻撃のゴールの一つとして非常に強い からです。
しかも今回は、別のLinux脆弱性 Copy Fail が、すでに実際の攻撃で悪用されていると記事は伝えています。
米CISAも Copy Fail を Known Exploited Vulnerabilities（KEV） Catalog に追加しており、連邦機関に対して期限付きで対処を求めています。
つまり流れとしては、
という、管理者にとってはかなり胃が痛い展開です。
個人的には、これは「Linuxは安全じゃない」という単純な話ではなく、人気OSだからこそ研究対象にも攻撃対象にもなりやすい という現実を映していると思います。
記事の更新によると、Dirty Fragでつながれている2つの page-cache write 脆弱性には、後からCVEが割り当てられました。
CVE は、脆弱性に付く管理番号のようなものです。
これが付くと、ベンダー側の修正や追跡がしやすくなります。
ただし、CVEが付いた＝もう安心 ではありません。むしろ、ここからが本番です。対応、検証、適用、再起動、影響確認……運用の地味で大変な仕事が待っています。
Dirty Frag は、Linuxのカーネル深部にある問題を組み合わせて、ローカルからroot権限まで持っていける可能性がある という、かなり嫌なゼロデイです。
しかも、最近は Copy Fail のような類似の権限昇格脆弱性が実際に悪用されているため、Linux管理者はかなり警戒したほうがいい状況です。
ただし、すべての環境が等しく危険というより、特定のモジュールや設定条件が関係する ので、まずは自分の環境で該当するかを確認するのが現実的です。
そして、パッチが出たらできるだけ早く適用する。これに尽きます。
正直、こういうニュースを見るたびに「カーネルの世界は本当に一筋縄ではいかない」と思います。
便利さと引き換えに、OSの土台にはこんなに複雑な爆弾が潜んでいるわけですから、システム管理者の仕事はほんとうに大変です。
参考: New Linux 'Dirty Frag' zero-day gives root on all major distros