SpaceXのセキュリティエンジニアがLinuxカーネルのCIFSサブシステムに存在する特権昇格脆弱性「CIFSwitch」を発見・公開した。非特権ユーザーが細工したリクエストを送ることでroot権限を取得できるため、CentOS Stream 9、Rocky Linux 9、AlmaLinux 9、Kali Linux、Linux Mint等の複数ディストリビューションを使う環境では早急な対応が求められる。

CIFSwitchとは何か

CIFSwitch（CVE未割り当て、通称名）は、LinuxカーネルのCIFSサブシステムとユーザースペースのヘルパーツール群「cifs-utils」の間の認証連携に潜む欠陥だ。名前の由来はCIFS（Common Internet File System）と、攻撃の核心にある「名前空間スイッチ（namespace switch）」を組み合わせたもの。

CIFSはWindowsファイル共有などでも使われるネットワークファイルアクセスプロトコルであり、Linuxが社内ネットワーク上のWindowsサーバーや NASにマウント接続する際に広く利用されている。Kerberos認証を使ったCIFSマウントを行う場合、カーネルはユーザースペース側のヘルパープログラム（cifs.upcall）に認証処理を委任する仕組みになっている。

攻撃の仕組み

問題の核心は、カーネルのCIFSサブシステムが cifs.spnego タイプのキーリクエストの発信元を検証していない点にある。

通常の認証フローでは、カーネル自身が cifs.spnego タイプのキーリクエストを発行し、root権限で動作する cifs.upcall がそれを受け取ってKerberos/SPNEGO認証情報を構築する。しかしカーネルが発信元を検証しないため、非特権ユーザーが偽の cifs.spnego リクエストを作成し、同じ認証ワークフローを起動できてしまう。

この偽リクエストには攻撃者が制御するフィールドが含まれており、cifs.upcall はそれをカーネル由来の正規データとして信頼する。攻撃者はそのフィールドを悪用して名前空間スイッチ（namespace switch）を強制実行させ、権限を落とす前のタイミングでName Service Switch（NSS）ルックアップを発生させる。そこに悪意あるNSSモジュールを差し込むことで、root権限でのコード実行が実現する。

この脆弱性は2007年に導入されており、実に19年間パッチが当たらないまま存在していたことになる。発見者はSpaceXのセキュリティエンジニアであるAsim Viladi Oglu Manizada氏であり、詳細な技術レポートとともに検証用のPoC（概念実証）エクスプロイトも公開済みだ。

影響を受けるディストリビューション

脆弱性の悪用にはいくつかの前提条件が重なる必要がある：

  • 脆弱なカーネルバージョン
  • cifs-utils 6.14以上（または一部の旧バージョン）
  • ユーザー名前空間（user namespaces）が利用可能
  • SELinux/AppArmorがこの攻撃をブロックしない設定

デフォルト設定で脆弱と確認されているディストリビューション：

ディストリビューション バージョン

Linux Mint 21.3 / 22.3

CentOS Stream 9

Rocky Linux 9

AlmaLinux 9

Kali Linux 2021.4〜2026.1

SLES 15 SP7

cifs-utilsがインストールされている場合、Ubuntu、Debian、Pop!_OS、openSUSE、Oracle Linux、Amazon Linuxの一部バージョンも影響を受ける可能性がある。

一方、デフォルトのSELinux/AppArmor設定により保護されているディストリビューションとして、Ubuntu 26.04、Fedora 40〜44、CentOS Stream 10、Rocky Linux 10、SLES 16、AlmaLinux 10などが確認されている。Amazon Linux 2とKali Linux 2019.4/2020.4は名前空間スイッチ機能自体がないため影響なし。

対処方法

カーネルパッチ（upstream commit 3da1fdf）で修正済みであり、各ディストリビューションのアップデートを適用することが最優先だ。パッチ適用が困難な場合の暫定対処として、発見者は以下を推奨している：

  • CIFSモジュールを無効化またはブラックリストに追加（未使用の場合）
  • cifs-utilsパッケージを削除（不要な場合）
  • 非特権ユーザーの名前空間を無効化

PoC公開済みであるため、パッチ適用の優先度は高い。既存パッチの有効性確認にもPoCを活用できる。

実務への影響

日本のエンタープライズ環境でLinux×Windowsファイル共有（CIFS/SMB）は珍しくない構成だ。特にオンプレミスのActive DirectoryにKerberos認証で接続しているLinuxサーバーが存在する環境では、このシナリオに当てはまるケースがある。

確認すべき優先事項は以下の通り：

  • 影響対象ディストリビューションのリストアップ: 特にCentOS Stream 9、Rocky Linux 9、AlmaLinux 9は日本でも採用実績が多い
  • cifs-utilsの有無を確認: rpm -q cifs-utils または dpkg -l cifs-utils で確認。使っていないなら削除が手っ取り早い
  • カーネルアップデートの適用: 各ディストリのセキュリティアドバイザリを参照し、修正済みカーネルバージョンを確認して更新
  • SELinux/AppArmorの有効化: 有効化されていれば本脆弱性に対して保護される。「設定が面倒だから無効にしている」という環境は今すぐ見直しを

ローカル特権昇格であるため、外部からの直接攻撃ではなく「侵入した後の権限昇格」や「内部不正」のシナリオで使われるリスクが高い。侵入後の影響を最小化する多層防御の観点からも看過できない。

筆者の見解

19年前に入り込んだ欠陥が今になって表面化するというのは、オープンソースソフトウェアの両面性をよく示している。コードが公開されているからこそ今回のように研究者が発見・報告できるわけで、それ自体は健全なエコシステムが機能している証拠だ。

ただ、実際に影響を受ける組織の多くにとってはその健全性よりも「今夜どうするか」の話になる。特にSELinuxを「面倒だから無効」にしてきた環境は、今回のような脆弱性が一発で刺さる構造を自ら作り出している。SELinux/AppArmorはセキュリティレイヤーとして機能していることが今回の対比でも明確に示された。

またゼロトラストの観点からは、ローカル特権昇格が脅威になる時点でサーバーへのアクセス管理も問い直したい。「そのサーバーに誰がログインできるか」「最小権限で動いているか」という基本が徹底されていれば、攻撃者がこの脆弱性を使うための足がかりそのものを減らせる。

PoC公開済みという事実は重く受け止めるべきだ。理論上の話ではなく、動くコードが出回っている。対応を後回しにする理由はない。

出典: この記事は New CIFSwitch Linux flaw gives root on multiple distributions の内容をもとに、筆者の見解を加えて独自に執筆したものです。