Linuxカーネルのntfs3ドライバに権限昇格の脆弱性。報告から2ヶ月間未修正

Linuxカーネルのntfs3ファイルシステムドライバに、細工されたNTFSイメージをマウントするだけでroot権限が奪取される脆弱性が見つかった。6月の報告から2ヶ月間、メインラインカーネルに修正は入っていない。

Linuxカーネルのntfs3ドライバに権限昇格の脆弱性。報告から2ヶ月間未修正

Linuxカーネルのntfs3ファイルシステムドライバに、細工されたNTFSイメージをマウントするだけでroot権限が奪取される脆弱性が見つかった。6月の報告から2ヶ月間、メインラインカーネルに修正は入っていない。


ディスク上の「嘘」をカーネルが信じる

セキュリティ研究者のウラジーミル・トカレフ(Vladimir Tokarev)氏が、ntfs3ドライバの権限昇格脆弱性を公開した。「InjectionBunny」と名付けられたこの脆弱性は、ntfs3がNTFSボリューム上の拡張属性をinode(ファイルの管理情報)に読み込む処理に存在する。

NTFSには、Windows Subsystem for Linux(WSL)が使用する特殊な拡張属性がある。$LXUID$LXGID$LXMODの3つで、それぞれLinux上でのファイル所有者、グループ、パーミッション(アクセス権限)を格納する。Linuxカーネルのntfs3ドライバは、NTFSボリュームをマウントする際にこれらの値を読み取り、各ファイルのinodeに反映する。

問題はfs/ntfs3/xattr.cntfs_get_wsl_perm()関数にある。この関数は$LXMODの値をinode->i_modeマスクなしで代入する。SUID(Set User ID、実行時にファイル所有者の権限で動作するフラグ)やSGID(Set Group ID)といった危険なビットを除去する処理が一切ない。

つまり、攻撃者がNTFSイメージのMFT(Master File Table、NTFSのファイル管理構造)に$LXUID=0(root)、$LXGID=0(root)、$LXMOD=0104755(SUIDビット付きの実行可能ファイル)を書き込んでおけば、そのボリュームがマウントされた瞬間、中のバイナリはカーネルから「rootが所有するSUID付き実行ファイル」として認識される。実行すればeuid=0を得てrootシェルが立ち上がる。

InjectionBunny 脆弱性の仕組み
NTFSボリューム上のWSL拡張属性$LXUID=0, $LXGID=0, $LXMOD=SUID付きntfs3ドライバがマウント時に読み取りntfs_get_wsl_perm()⚠ inode->i_modeに代入SUIDビットのマスク処理なしカーネルがSUID付きファイルとして認識権限昇格の脆弱性が成立
※赤枠のステップがntfs3ドライバの設計不良箇所。修正案はこの代入処理にビットマスクを追加するだけで済む

トカレフ氏はPoC(概念実証)ツール一式を公開している。Pythonスクリプトでmkfs.ntfsが生成したNTFSイメージのMFTレコードを直接パッチし、WSL拡張属性を注入する。タイミングに依存するレースコンディション(競合状態)やメモリ操作は不要で、ディスクイメージの生成とマウントだけで成立する

攻撃が成立する条件

影響を受けるのはCONFIG_NTFS3_FSが有効なLinuxカーネル(5.15以降、ntfs3がメインラインに統合された時点から)で、Ubuntu 22.04以降、Debian 12以降、Fedora 36以降、RHEL 9以降など主要ディストリビューションの大半が該当する。CVSS(脆弱性の深刻度を示す共通指標)のスコアは6.8で、物理アクセスが前提となる。

ただし、攻撃が実際に成立するには、NTFSボリュームがnosuidオプションなしでマウントされている必要がある。nosuidが付いていれば、カーネルはプログラムの実行時にSUIDビットを無視するため、euid=0への昇格は起こらない。

ここで重要なのは、多くのLinuxデスクトップ環境で使われている自動マウント機構のudisks2が、セキュリティ上の理由からnosuidを常に付加する設計になっている点にある。設定ファイルからも変更できない固定オプションとして組み込まれており、USBドライブを挿した際のデスクトップ環境での自動マウントでは、通常この攻撃は成立しない。

攻撃が成立する主な経路は以下の通り。

  • mount -t ntfs3で手動マウントし、明示的にnosuidを指定しなかった場合(mountコマンドのデフォルトはsuid許可)
  • fstabにntfs3パーティションをnosuidなしで記載している場合
  • ループデバイス経由でNTFSイメージをマウントした場合
  • udisks2の設定をカスタマイズしてnosuidを外している場合

トカレフ氏の報告書では「デスクトップの自動マウント機構はNTFSをsuid付きでマウントする」と記載されているが、現行のudisks2ではこの記述は正確ではない。とはいえ、手動マウントやスクリプトによるマウントではnosuidが付かないケースは珍しくなく、脆弱性そのものの深刻さは変わらない。ディスク上の信頼されていないデータからSUIDビットが読み込まれること自体が、ファイルシステムドライバの設計として問題がある。

報告から2ヶ月、修正は入っていない

トカレフ氏は現地時間2026年6月25日に[email protected]へ脆弱性を報告した。約2ヶ月間応答がなく、8月7日にntfs3のサブシステムメンテナ宛てにメーリングリストへ転送している。

InjectionBunny 報告から公開までの経過
6月25日
報告書とPoCを添付して送付。約2ヶ月間応答なし
7月
CVE-2026-63833がマージ
setxattr()経由の書き込みをブロック。ディスク上のEA読み込み経路は未修正
8月7日
メーリングリストへ転送
ntfs3メンテナ宛てに主要ベクタの未修正を指摘
8月22日
脆弱性が報道される
メインラインカーネルに修正なし。PoCとレポートが公開状態
※日付はいずれも2026年(現地時間)

この間、関連するCVE-2026-63833(コミットf8d420949b33)が割り当て・マージされた。しかしこの修正はsetxattr()経由で$LX*名への書き込みをブロックするもので、ディスク上に最初から存在するEA(拡張属性)を読み込む経路には対処していない。トカレフ氏が報告した主要な攻撃ベクタは未修正のまま残っている。

修正案はたった1行の変更で済む。

inode->i_mode = le32_to_cpu(value[2]) & ~(S_ISUID | S_ISGID);

ディスクから読み込んだパーミッション値にビットマスクをかけ、SUIDとSGIDを除去するだけの処理を追加すればよい。

ntfs3ドライバはParagon Software(パラゴン・ソフトウェア)が開発し、2021年のLinux 5.15でメインラインに統合された。メンテナはコンスタンティン・コマロフ(Konstantin Komarov)氏だが、統合後の開発ペースは鈍化しており、メンテナンスの手薄さはLinuxコミュニティで以前から指摘されてきた。

一方、Linux 7.1ではナムジェ・ジョン(Namjae Jeon)氏が4年かけて開発した新しいNTFSドライバがメインラインに統合されている。こちらはntfs3とは別のコードベースで、旧来のカーネル内NTFSドライバを全面的に書き直したもの。Phoronixの報道によれば、今回の脆弱性は新NTFSドライバには影響しない。

現在開かれているLinux 7.3のマージウィンドウでは、ntfs3に21コミット・922行のセキュリティ修正が入っている。境界外書き込みや情報リーク、整数オーバーフローなどが対象だが、今回のSUID注入問題がこの修正群に含まれているかは確認できていない。

ドライバの設計不良が残り続ける構造

ntfs3のntfs_get_wsl_perm()がディスク上のパーミッション値をそのまま信用する設計は、ファイルシステムドライバとしての基本的な見落としにあたる。NTFSはLinuxのパーミッション体系を持たないファイルシステムであり、WSL拡張属性はWindows環境で任意に書き込める外部入力にすぎない。外部入力から取得した値は信頼されていない入力として扱い、SUIDやSGIDのような危険なビットを除去してからinodeに反映すべきだった。

旧ntfsドライバ(fs/ntfs/ea.cntfs_ea_get_wsl_inode())にもこのパターンが存在するとトカレフ氏は指摘している。

Linuxユーザーが今すぐ取れる対策は明確で、NTFSボリュームのマウント時にnosuidオプションを明示的に指定すること、あるいはntfs3からLinux 7.1以降で利用可能な新NTFSドライバへ切り替えることになる。fstabにntfs3のエントリがある場合は、nosuidが含まれているか確認しておくべきだろう。

修正に必要なのはマスク処理の1行。それが2ヶ月入らないまま、脆弱性の詳細とPoCが公開された。

関連記事

この記事を共有する

Read more