copyfail-deconstructed

CVE-2026-31431 のわかりやすいバージョンです。これは、誰でも root になれる権限昇格手法です。オリジナルの proof-of-concept は https://github.com/theori-io/copy-fail-CVE-2026-31431 にありますが、フットプリントをできるだけ小さくするために、高度に圧縮・縮小化されています。このリポジトリは、そのコードをより読みやすい形に分解し、コードが何を行うか、ペイロードがどのようにロードされるか、異なるアーキテクチャをターゲットにする方法を説明することを目的としています。より技術的な解説はこちら: https://xint.io/blog/copy-fail-linux-distributions

使用方法

デフォルトでは、python3 copyfail.py を実行すると、/usr/bin/su を悪用する x64 シェルコードが実行されます。独自のペイロードを指定するには、python3 copyfail.py [path/to/custom/payload.elf] を実行します。例として、payloads/ 内に ARM64 シェルコードのアセンブリがあります。ARM64 デバイスでテストするには、まずカスタムリンカスクリプトを使って最小化されたペイロードをビルドする必要があります:

as -o shellcode_aarch64.o payloads/shellcode_aarch64.S
ld -nostdlib -static -o shellcode_aarch64.elf shellcode_aarch64.o
strip -s shellcode_aarch64.elf

その後、python3 copyfail.py shellcode_aarch64.elf を使ってメインのエクスプロイトを実行できます。

C で実行する場合:

1. ビルドします（下記参照）
2. ./c_copyfail を実行します。これは上記と同じデフォルトのシェルコードを実行します。

• 独自のペイロードを指定するには、./c_copyfail [path/to/custom/payload.elf] を実行します。

C バージョンのビルド:

cd c_port
make

具体的には、ターゲットの .S ファイルを raw バイナリにコンパイルし、C の unsigned char 配列として出力します:

gcc -c payloads/[shellcode].S
objcopy -O binary [shellcode].o [payload].raw
xxd -i [payload].raw > payload.txt

または、32 ビット x86 の場合:

gcc -c -m32 payloads/[shellcode].S
objcopy -O binary [shellcode].o [payload].raw
xxd -i [payload].raw > payload.txt

このファイルの内容をソースコードにコピーするか、あるいは ./c_copyfail.exe [path/to/payload.elf] を直接実行することもできます。ここで payload.elf は as + ld で生成されたものであり、gcc + objcopy ではありません。

修正方法

悪用を防ぐには、次を実行します:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

すでに悪用されている場合は、マシンを再起動するか、次を実行します: echo 3 | sudo tee /proc/sys/vm/drop_caches

解説

1. カーネルはソケットタイプ AF_ALG を通じてユーザーが crypto API と通信できるようにしている

• 2017 年に crypto API の algif_aead 部分に「in-place 最適化」が追加された
• splice() システムコールを使ってソケット経由でデータが送信されると、カーネルはスプライスしたファイルの実際のページキャッシュページを crypto 作業領域に配置する
• crypto アルゴリズム authencsn は出力バッファをスクラッチ領域として扱い、本来の場所より 4 バイト先に書き込む

2. 仮想的な攻撃者ができること

• 任意の読み取り可能なファイルを選択する（例: この場合は /usr/bin/su）
• そのファイル内で 4 バイト書き込みが発生するオフセットを選択する
• 書き込む 4 バイト値を選択する（AEAD 操作の associated data の一部）
• ファイルをメモリ上で上書きするシェルコードを書き込む

3. ページキャッシュ上書きによる root 化

• カーネルは破損したページをダーティとしてマークしないため、ファイルは変更されていないように見える
• /usr/bin/su を実行するとき、カーネルはページキャッシュからそれを読み取り、変更されたバイトを取得する
• 4 バイト書き込みを繰り返す（約 40 回）ことで、/usr/bin/su 内の UID チェックを上書きし、UID を 0（root）にする
• 任意のユーザーで root シェルを獲得できる

4. 修復策

• ページキャッシュをフラッシュしてメモリ内の変更されたファイルを削除し、次回はディスクから読み込ませる
• カーネルモジュールをアンロードする
• ロードをブラックリストに登録する
• 組み込みモジュールの場合は、seccomp または eBPF を使用してシステムコールをブロックする必要がある。または、初期化から除外してマシンを再起動する

su バイナリはメモリ上で破損しているため、ファイルの変更は検出されません。ディスクから復元するには、ページキャッシュをフラッシュできます。