「ただのファイル属性」がroot権限に化ける Linux ntfs3に潜んだ権限昇格のわな：Linuxカーネルが“ファイルのうそ”を信じた

LinuxカーネルのNTFSドライバー「ntfs3」に、一般ユーザーの権限をrootまで引き上げられる脆弱性が報告された。複雑な攻撃技術は必要ないという。カーネルが「信じてしまったもの」は何だったのか

[＠IT]

　LinuxカーネルのNTFSファイルシステムドライバー「ntfs3」に、細工したNTFSボリュームを利用して一般ユーザーがroot権限でプログラムを実行できる脆弱（ぜいじゃく）性「InjectionBunny」が報告された。複雑なメモリ破壊技術は必要ないという。問題の鍵を握るのは、カーネルが信頼した「ファイル属性」だった。

　問題を報告したのは、セキュリティ研究者のウラジーミル・トカレフ氏。同氏は2026年6月25日（現地時間、以下同）にLinuxカーネルのセキュリティ窓口へ報告し、同年8月7日には対応がなかったとして、ntfs3のメンテナーが利用しているとみられるメーリングリストへ報告を転送した。

「ただのファイル属性」がroot権限に化ける　ntfs3の信頼境界

　原因は「fs/ntfs3/xattr.c」の「ntfs_get_wsl_perm()」にある。ntfs3はNTFS上の「WSL」（Windows Subsystem for Linux）用拡張属性から「$LXUID」「$LXGID」「$LXMOD」を読み取り、Linux側のファイル所有者やパーミッションに反映する。

　問題は、$LXMODの値を「inode」の「i_mode」に反映する際、SUIDやSGIDに関係するビットを除去していなかったことだ。

　攻撃者は、例えば$LXUID=0、$LXGID=0、$LXMOD=0104755を設定したNTFSイメージを作成できる。これをLinux側でマウントすると、対象ファイルはroot所有のSUID実行ファイルとして認識される。

　一般ユーザーがこのファイルを実行すると、SUIDの仕組みによって実効UIDが0となり、root権限でプログラムを実行できる。報告されたPoC（概念実証）でも、UID、実効UID、GIDがいずれも0になることが確認された。

　攻撃には競合状態やヒープスプレーなどの複雑な技術を必要としない。想定される侵入経路の一つは細工したUSBドライブだ。ループデバイスを利用できる環境では、細工したNTFSイメージから攻撃できる。

　ただし、NTFSをマウントしただけでroot権限を奪われるわけではない。細工したボリュームがnosuidオプションを付けずにマウントされ、その中のSUID実行ファイルが実行されることが攻撃の条件となる。

SUIDを消すだけでは不十分　「信頼できないデータ」を権限に変えない

　影響を受けるのは、カーネルで「CONFIG_NTFS3_FS」が有効になっており、NTFSボリュームをnosuidなしでマウントする環境だ。USBドライブなどを自動マウントするLinuxデスクトップも条件に該当する。

　ウラジーミル・トカレフ氏は、$LXMODをLinux側へ反映する際にSUID（S_ISUID）とSGID（S_ISGID）のビットを除去する修正案を提示している。運用面では、NTFSボリュームをnosuidオプション付きでマウントすることで、SUIDを利用した攻撃を防げる。

　ただ今回の問題を「SUIDのビットを消し忘れたバグ」とだけ捉えるのは不十分だ。

　本質的な問題は、攻撃者が操作できるNTFSの「$LX*」属性を、カーネルがLinuxの権限情報として信頼してしまったことにある。Linuxカーネルでは、$LX*属性をユーザー空間から直接書き換えられないようにする修正も進められている。

　つまり開発者が考えるべきなのは、「危険な値を受け取ったらどう処理するか」だけではない。そもそも、その値を誰が変更できるのか。その値をどの時点でOSが信頼する情報へ変換するのかという境界まで設計する必要がある。

　これはファイルシステムドライバーに限った話ではない。外部から取得したファイル属性や設定値、メタデータなどをUID、GID、パーミッションといった権限情報へ変換する処理では、入力値だけでなく、その入力を操作できる経路そのものを検証する必要がある。

　なお、報告では「Ubuntu」「Debian」「Fedora」「RHEL」「SUSE」「Arch Linux」などが影響対象として挙げられている。問題はCPUアーキテクチャに依存するものではなく、PoCはLinux 7.1.0のaarch64環境で確認された。