CVE-2026-31431「Copy Fail」脆弱性の全体像と実務影響範囲

CVE-2026-31431「Copy Fail」脆弱性の全体像と実務影響範囲

本章ではCVE-2026-31431「Copy Fail」脆弱性の発見経緯と攻撃の特殊性、実務上の影響範囲を整理します。Theori社およびXint Code研究チームが2026年4月29日に公開した本脆弱性は、Linuxカーネルの暗号サブシステムに存在する論理欠陥に起因しており、非特権ユーザーが即座にroot権限を獲得できる極めて深刻な内容となっています。

2026年4月29日公開・Theori発表によるCVE-2026-31431の基本情報

CVE-2026-31431は2026年4月29日にセキュリティ企業Theoriの研究チームXint Codeが正式公開した、Linuxカーネル0-day脆弱性です。識別子はCVE-2026-31431、通称「Copy Fail」と呼ばれ、Linuxカーネルの暗号サブシステムにおけるalgif_aeadモジュール内の論理欠陥に起因します。最も重要な論点は、ローカル特権昇格(LPE: Local Privilege Escalation)を100%の信頼性で達成できる点にあり、レース条件や環境依存のチューニングを一切必要としない決定論的な実行特性を持っています。

協調的開示プロセスは2026年3月23日のTheoriからLinux kernel securityチームへの報告に始まり、わずか2日でパッチが提案され、4月1日にメインラインへコミット、4月22日にCVE番号が割り当てられました。最終的に4月29日に技術詳細とPoCが一般公開されています。被害想定は2017年以降にビルドされたほぼすべてのLinuxサーバーに及び、即時パッチ適用が各ディストリビューションベンダーから強く推奨されています。

不正な特権昇格を実現する732バイトPython PoCスクリプトの脅威度

Theoriが公開したPoC(Proof of Concept)は、わずか732バイト・約10行のPython 3.10標準ライブラリのみで構成されたスクリプトです。socket、os、zlibといった追加依存ゼロのモジュールだけで成立する点が特筆され、コンパイルやシェルコード生成、特殊なペイロード調整の工程を必要としません。攻撃者は対象サーバー上で当該スクリプトを実行するだけで、デフォルト動作として/usr/bin/suのページキャッシュ書き換えからroot shell獲得までを一気通貫で完了させます。

従来のLinuxカーネル脆弱性が要求していた「カーネルバージョン特定」「シンボルアドレス取得」「ROPチェーン構築」といった攻撃者側コストはCopy Failには存在しません。攻撃成功率は事実上100%であり、攻撃の敷居が極めて低い点が脅威度を押し上げる主要因として報告されています。Theori公式リポジトリ(github.com/theori-io/copy-fail-CVE-2026-31431)ではPoC本体(copy_fail_exp.py)が公開されており、加えてコミュニティ提供の非破壊型検出スクリプトもGitHub上で利用可能となっているため、実環境への影響確認手段が整備されている状況です。

Dirty Cow・Dirty Pipeとの比較で読み解く決定論的実行特性

Copy Failは過去の著名なLinuxローカル特権昇格脆弱性であるDirty Cow(CVE-2016-5195)やDirty Pipe(CVE-2022-0847)と比較されます。両者との決定的な違いは「レース条件を一切必要としない」点にあり、攻撃の信頼性と再現性が桁違いに高くなっています。下表は3脆弱性の主要属性を比較したものです。

Dirty Cowは仮想メモリのCopy-on-Writeレース条件を悪用したため、実機ではしばしばカーネルパニックを引き起こす不安定さが課題でした。Copy Failはこれと対照的に、暗号APIの正常実行フローを通じて意図された範囲外への書き込みを発生させるため、システムが落ちることなく静かに権限昇格が完了する性質を備えています。

2017年導入から9年間放置された潜在期間と静的解析の限界事例

Copy Failの脆弱性根因コミットは2017年6月のkernel 4.14系で取り込まれた72548b093ee3であり、その後9年間にわたり発見されませんでした。この長期潜在は単一のバグというより、2011年のauthencesn実装、2015年のAF_ALG AEAD対応、2017年のin-place最適化という3段階の独立した変更が交差した結果として顕在化したものです。各変更は単体では合理的であり、レビュー段階で見落とされた背景があります。

静的解析ツールやファジング、シンボリック実行といった既存のセキュリティ検証手法は、複数モジュールの相互作用に起因する論理欠陥を捕捉することが構造的に難しく、本件はその限界を示す象徴的な事例となりました。発見はTheoriが提供するAI支援型コード解析プラットフォームXint Codeを、同社研究者Taeyang Lee氏が活用し、約1時間で達成されたとされ、AI活用によるカーネル脆弱性発見の経済性が一気に変化したことが業界に衝撃を与えています。

ローカル特権昇格に留まらないコンテナ脱出プリミティブの危険性

Copy Failを単なるLPE(ローカル特権昇格)として捉えると、その本質的な危険性を見誤ります。Linuxのページキャッシュはホストカーネル単位で全プロセスから共有される構造を持つため、コンテナ内部で実行された攻撃が、ホスト上の他コンテナや特権プロセスのバイナリページキャッシュにまで波及する設計上の特性があります。これによりCopy Failは事実上のコンテナ脱出プリミティブとして機能する経路を持つ点が特徴です。

具体的には、Kubernetesクラスタ上で1つのPodが侵害された場合、攻撃者は同一ノード上の別Podが利用するsetuidバイナリのページキャッシュを書き換え、そのバイナリ実行のタイミングでroot権限を奪取できます。マルチテナント型クラウド環境やCI/CDランナー、共有ビルドサーバーといった「他者のコードを同一カーネルで実行する」アーキテクチャ全般が深刻なリスクに晒されており、単体ホストの権限境界突破に留まらない広範な影響が懸念されます。

authencesn暗号テンプレートに潜む4バイト書き込みの根本原因

本章ではCopy Failの技術的根因であるauthencesn暗号テンプレートの設計と、4バイト書き込みが発生する内部メカニズムを掘り下げます。問題は単一コミットではなく、複数年にわたる独立した最適化の交差点に存在しており、根本原因の理解は防御策設計の前提となります。

IPsec ESP拡張シーケンス番号RFC 4303対応で導入された経緯

authencesnは2011年にLinuxカーネルへ導入されたAEAD(Authenticated Encryption with Associated Data)テンプレートです。導入コミットはa5079d084f8bであり、目的はIPsec ESP(Encapsulating Security Payload)のRFC 4303で規定された64ビット拡張シーケンス番号(ESN: Extended Sequence Numbers)サポートを実現することでした。ESNは長期間継続するIPsecトンネルでシーケンス番号枯渇を回避するための拡張であり、上位32ビットを認証計算に組み込む処理が必要となります。

導入当初のauthencesnは、呼び出し側の宛先scatterlistを「ESNバイト並べ替え用の作業領域」として使用する設計が採用されていました。この時点では旧AEADインターフェースで関連データ(AAD)が独立したscatterlistに存在しており、唯一の呼び出し元はカーネル内部のxfrm層に限定されていました。中間書き込みが外部から観測される機会は存在せず、当時の実装は実害なく稼働していたと報告されています。設計時の前提と、後に追加された呼び出し経路との不整合が、9年越しの脆弱性として顕在化することになります。

出力境界外へ書き込む4バイトscratch writeの動作仕様

authencesnの内部実装は、暗号処理の中間状態として「dst[assoclen + cryptlen]」位置にAADのseqno_lo領域から取得した4バイトを書き込む仕様を持ちます。これはESNの上位32ビットを認証ハッシュ計算前に一時格納する作業書き込み(scratch write)であり、本来は呼び出し側の出力バッファ内部に収まることを暗黙に前提とした設計です。問題は、宛先scatterlistの末尾境界を超えた位置に書き込みが発生する点にあります。

標準的なAEADアルゴリズムであるGCM、CCM、通常のauthencは、いずれも自らの書き込み範囲を正規の出力領域内に厳密に閉じ込めて動作します。authencesnのみが出力境界の外側に書き込む独自挙動を持っており、この4バイトscratch writeこそがCopy Failの直接的な攻撃プリミティブを提供しています。攻撃者はsplice file offset、splice length、assoclenの3パラメータを調整することで、ページキャッシュ内部の任意の4バイト位置を制御可能な仕様です。

2011年・2015年・2017年の3段階変更が交差した複合要因

Copy Failの本質は、独立した3つの変更が時間差で交差した複合要因にあります。各変更は単独では合理的かつ局所最適であり、レビュー時点では問題視されませんでした。下記の時系列で各変更の役割を整理します。

1. 2011年:authencesn導入(commit a5079d084f8b) – IPsec ESN対応のため宛先scatterlistを作業領域として使用する仕様を採用
2. 2015年前半:AF_ALG AEADサポート追加(algif_aead.c) – 非特権ユーザーから暗号APIを呼び出す経路を新設、splice()でページキャッシュページを直接渡せる構造を導入
3. 2015年後半:authencesn新AEADインターフェース移行(commit 104880a6b470) – assoclen + cryptlenオフセットへの書き込み仕様が確立
4. 2017年:in-place最適化(commit 72548b093ee3) – req->src = req->dstへ統合、ページキャッシュページが書き込み可能なscatterlistに混入する経路が成立

2011年から2015年までの期間は、authencesnの呼び出し元がカーネル内部のxfrm層に限定されていたため、scratch writeは実害をもたらしませんでした。2015年のAF_ALG AEAD対応で外部呼び出し経路が開かれた段階でも、in-place最適化が未実装であったため、req->srcとreq->dstは別scatterlistとして分離され安全性が維持されています。決定打は2017年のin-place最適化であり、ここで初めて3要素が連鎖し、ページキャッシュ書き換えが現実の攻撃経路として成立しました。

GCM・CCM・authencとauthencesnの境界書き込み挙動比較

Linuxカーネルが標準的にサポートするAEADアルゴリズムのうち、出力境界を超えた書き込みを行うのはauthencesnのみであることが、Theoriの調査で確認されています。下表は主要AEADアルゴリズムの境界書き込み挙動を比較したものです。

この挙動差は、authencesnがESN処理という特殊用途のために出力バッファをscratch領域として使い回す設計上の妥協を内包していることに起因しています。一般的なAEADは出力範囲の規律が厳密であり、ページキャッシュページが書き込み可能scatterlistに混入してもデータ破損は発生しません。authencesnのみが「他のAEADと前提が異なる」点を、in-place最適化の設計者が把握していなかった構造的見落としが、9年潜在の根本要因として明らかになっています。

assoclen+cryptlenオフセット計算で発生する書き込み位置制御性

攻撃者がページキャッシュ内部の特定4バイトを正確に書き換えられる理由は、書き込み位置がassoclenとcryptlenという呼び出し側パラメータで決定されるためです。具体的には宛先scatterlistの先頭からassoclen + cryptlenバイト目に4バイトが書き込まれる仕様となっており、攻撃者はsendmsg時のAAD長と暗号文長を任意に調整することで、書き込み相対位置を1バイト単位で制御できます。

さらにsplice()でファイルをパイプ経由でAF_ALGソケットへ流し込む際のファイルオフセット指定により、ページキャッシュ内の絶対位置も自由に選択可能です。この2軸の組み合わせにより、攻撃者は対象ファイル(/usr/bin/suや/etc/passwd等の任意の読み取り可能ファイル)のページキャッシュ内部における任意4バイト領域を、自身が指定した値で上書きできます。書き込み内容自体はAADのseqno_lo領域(バイト4-7)から取得されるため、4バイトの値そのものも攻撃者が完全に制御可能となっています。

AF_ALG・splice・ページキャッシュ連鎖による特権昇格の成立条件

本章ではCopy Failの攻撃チェーンが成立する3つのカーネル機能の連鎖、すなわちAF_ALGソケット・splice()システムコール・ページキャッシュ書き込みの組み合わせを技術的に解説します。各要素の役割を理解することは、検知設計と暫定回避策の選定に直結します。

AF_ALGソケットが非特権ユーザーに暗号API公開する設計上の前提

AF_ALGはLinuxカーネル2.6.38で導入されたソケットファミリで、ユーザー空間プロセスがカーネル内部の暗号処理を直接呼び出せるインターフェースを提供します。設計上の最大の特徴は、非特権ユーザーであっても任意のAEADテンプレートを名前指定でバインドし、暗号化や復号操作を発行できる点にあります。具体的にはsocket(AF_ALG, SOCK_SEQPACKET, 0)でソケットを生成し、bind()時に”aead”とアルゴリズム名を指定するだけで、追加権限を要求されずに暗号サブシステムへアクセス可能な仕様です。

この前提は「カーネル暗号APIの提供範囲を拡張する」設計判断に基づいており、本来はOpenSSL等のユーザー空間暗号ライブラリの代替や、ハードウェア暗号アクセラレータの活用を意図したものでした。しかしCopy Failの観点では、攻撃者が事前権限なしでauthencesnテンプレートに到達できることが攻撃成立の必須条件となっており、AF_ALGの広範な公開設計が攻撃面を大きく拡大させる要因として機能しています。多くの主要ディストリビューションでデフォルトカーネルコンフィグでAF_ALGが有効化されているため、追加の構成変更なく攻撃が成立する点が脅威度を押し上げる構造となっています。

splice()でファイルページをsg_chain経由で渡す攻撃チェーン

Copy Failの攻撃チェーンは、splice()システムコールでファイルのページキャッシュページをパイプに移動させ、続いて再度splice()でAF_ALGソケットへ流し込む二段構成で成立します。splice()はゼロコピーI/Oを実現するための仕組みで、ファイルディスクリプタとパイプ間でページ参照を直接移動させ、対象ファイルのページキャッシュページがそのままパイプバッファに登録される動作を持ちます。

1. AF_ALGソケットを開きauthencesn(hmac(sha256),cbc(aes))にbind
2. 対象ファイル(例:/usr/bin/su)を読み取り専用でopen
3. splice()でファイル内容をパイプへ移動、ページキャッシュページが直接パイプに登録される
4. 2回目のsplice()でパイプからAF_ALGソケットへページを送信
5. カーネルが受け取り側scatterlistを構築、ページキャッシュページがsg_chain経由で組み込まれる
6. recvmsg()で復号要求を発行し、authencesnのscratch writeがページキャッシュへ到達

攻撃チェーンの肝は、scatterlistにページキャッシュページが直接含まれる点にあります。通常のAEAD呼び出しではユーザー空間バッファが使われるため、書き込みが発生してもユーザー領域への副作用に留まりますが、splice経路ではカーネルが管理するページキャッシュ自体に書き込みが直撃する設計となっています。

req->src=req->dst化したin-place最適化が崩した境界保護

2017年のcommit 72548b093ee3で導入されたin-place最適化は、AEAD処理時に「ソースscatterlistと宛先scatterlistを同一メモリで共用する」変更でした。最適化の目的はメモリコピー削減によるスループット向上で、req->src = req->dstと設定することで暗号処理の作業領域として呼び出し側バッファを再利用する設計です。性能上は合理的な改善であったものの、この変更がページキャッシュ書き換えへの最後の障壁を取り除く結果を招きました。

in-place最適化前は、AF_ALG AEADの呼び出しでもreq->srcとreq->dstは独立したscatterlistとして分離されていたため、たとえsrc側にページキャッシュページが含まれていても、dst側は別途確保されたカーネルバッファであり書き込みが安全に閉じ込められていました。in-place化により、splice経由で渡されたページキャッシュページがそのまま書き込み先として再利用される経路が成立し、authencesnのscratch writeがページキャッシュに直接到達する状況が生まれた事実が、Theoriの解析で明確に示されています。修正パッチではこのin-place最適化を撤回し、out-of-place動作へ復帰させる方針が採用されました。

/usr/bin/suの4バイト改竄でroot権限を獲得する実装例

Theoriが公開した標準的な攻撃シナリオは、/usr/bin/suというsetuid-rootバイナリのページキャッシュを4バイト改竄してroot shellを獲得する手順です。/usr/bin/suは主要ディストリビューション全てに標準搭載されており、setuidビットが立っているため実行時に呼び出し元プロセスがファイル所有者であるrootの権限で動作します。攻撃者は実行可能命令の特定オフセットに対して4バイト書き込みを行い、認証スキップやシェル起動命令を埋め込みます。

別の攻撃変種として、/etc/passwdのページキャッシュ上で自身のUID欄を「0000」に書き換える手法も実証されており、この場合は次にsuコマンドを実行した際にlibcがUID 0と認識し、root shellが直接得られます。Theori公式リポジトリ(github.com/theori-io/copy-fail-CVE-2026-31431)で公開されているPoC本体のファイル名はcopy_fail_exp.pyであり、コミュニティ提供の派生実装(github.com/rootsecdev/cve_2026_31431)では非破壊検出スクリプトと併せて以下のコマンド形式が示されています。

python3 exploit_cve_2026_31431.py --shell

実行後、攻撃者は自身のパスワード入力のみでroot権限のシェルセッションを取得します。書き込み対象はディスク上のファイルではなくメモリ上のページキャッシュであるため、再起動後は変更が消滅しますが、稼働中のセッションでは即座に有効となる点に注意が必要です。

AAD seqno_lo領域の4バイト制御による任意書き込みの実現方法

書き込まれる4バイトの値は、攻撃者がsendmsg時に指定するAAD(Associated Data)のバイト4-7、すなわちseqno_lo領域から取得されます。AADはAEAD処理において認証対象に含まれるが暗号化されないデータ領域であり、攻撃者は任意の値をsendmsg呼び出し時に指定できます。authencesnの実装はこのseqno_lo領域を内部的にscratch領域へコピーする際、宛先scatterlistの境界外位置へ書き込むため、結果として攻撃者制御の4バイトがページキャッシュに到達する流れが成立する仕様です。

書き込み位置はassoclen + cryptlenオフセットで決定されるため、攻撃者はsendmsg時のAAD長と暗号文長を任意に調整することで、書き込み相対位置を制御可能です。さらにsplice file offsetと組み合わせることで、対象ファイルのページキャッシュ内における絶対位置を指定できます。HMAC計算自体は偽造された暗号文に対して必ず失敗するためrecvmsg()はエラーを返しますが、4バイトのscratch writeは検証ステップ前に実行されるため、エラー発生後もページキャッシュへの書き込みが永続する点が攻撃の中核仕様となっています。

影響カーネル4.14以降と主要Linuxディストリビューション別被害範囲

本章ではCopy Failの影響範囲を、カーネルバージョン軸とディストリビューション軸の両面から整理します。自社環境が脆弱性の影響を受けるかどうかの判定は、本章の情報を基準に進めることが推奨されます。

kernel 4.14導入commit 72548b093ee3が示す影響開始ポイント

Copy Failの影響開始ポイントはLinuxカーネル4.14系で取り込まれたcommit 72548b093ee3aであり、このコミットがin-place AEAD最適化を導入した起点となります。kernel.orgのCVE発表資料によれば、本commitを含むすべての安定版カーネルが影響対象であり、修正パッチが適用されていない4.14以降のカーネルすべてが脆弱な状態に置かれています。具体的な修正バージョンは6.18.22(commit fafe0fa2995a)、6.19.12(commit ce42ee423e58)、7.0(commit a664bf3d603d)で、これらより古いマイナーバージョンは原則として全数が対象です。

影響範囲が9年に及ぶ理由は、72548b093ee3aが安定版カーネルの長期サポート(LTS)系列にも含まれているためです。kernel 4.14、4.19、5.4、5.10、5.15、6.1、6.6、6.12といったLTS系列はそれぞれ数年単位で運用されており、企業や組織で長期稼働中のシステムも例外なく影響を受けます。古いLTSカーネルでベンダーがサポート期間外と判断した場合は、後述するalgif_aead無効化等の暫定対応へ移行する必要が生じます。

Ubuntu・RHEL・SUSE・Amazon Linuxの被害確認バージョン一覧

Theoriが直接実機検証で被害を確認した主要4ディストリビューションの該当バージョンは下表のとおりです。いずれもデフォルトカーネルコンフィグで攻撃が成立することが報告されています。

表に明記された4ディストリビューションは2026年4月29日時点でTheori/Xint Codeが現物検証で攻撃成立を確認したものであり、これら以外のバージョン(Ubuntu 22.04 LTS、RHEL 8/9系等)も脆弱commitを含む限り同様に影響を受けます。各ベンダーは公式アドバイザリで対象カーネルパッケージのバージョン情報を順次公開しており、適用判定はベンダー提供のセキュリティアップデート情報を一次ソースとして確認することが基本となります。

Debian・Arch・Fedora・Rocky・AlmaLinuxへの影響波及範囲

主要4ディストリビューション以外の派生・関連系統にも被害が広範囲に波及していることが、追加検証で明らかになっています。Theoriの公開情報および各コミュニティの確認結果によれば、以下のディストリビューションが脆弱commitを含むカーネルを配布している点が確認されました。

• Debian(stable・testing・unstable全系列で2017年以降のカーネル)
• Arch Linux(ローリングリリース、未パッチカーネルはすべて影響)
• Fedora(38/39/40/41系列の標準カーネル)
• Rocky Linux(8/9系列、RHEL互換系統)
• AlmaLinux(8/9系列、RHEL互換系統)
• Oracle Linux(7/8/9系列、UEKおよびRHCKの両カーネル)
• 各種組み込みLinux(Yocto系、Buildroot系のカスタムビルド)

影響判定の基本原則は「kernel 4.14以降であれば脆弱、ただし各ベンダーが個別にバックポートパッチを提供している場合は適用済みかを確認」となります。OracleやSUSEの一部商用カーネルは独自のパッチ管理体系を持つため、ベンダー固有のセキュリティ通告を確認することが運用上の必須プロセスとして位置づけられます。

コンテナベースイメージ別の脆弱カーネルバージョン判定手順と確認観点

コンテナ環境ではホストカーネルが脆弱性の判定基準となるため、コンテナベースイメージの選択ではなくホストOS側のカーネルバージョン確認が最優先となります。コンテナ内部で稼働するアプリケーションは独自のカーネルを持たず、ホストカーネルを共有するため、コンテナ内でいくら最新OSイメージを使用していてもホスト側のalgif_aeadが脆弱であれば攻撃が成立します。

1. ホストOS上でuname -rを実行し稼働カーネルバージョンを確認
2. ベンダー提供のセキュリティアドバイザリで該当バージョンが修正済みかを照合
3. 未修正の場合はcat /proc/modules | grep algif_aeadでモジュールロード状況を確認
4. 非破壊検出スクリプト(test_cve_2026_31431.py)を権限のあるホストで実行
5. 判定結果に応じてパッチ適用または暫定無効化のいずれかを選択

Kubernetesクラスタの場合はノードプール単位での確認が必要であり、各ノードに対して同一の判定プロセスを実施します。マネージドKubernetes(EKS、GKE、AKS等)を利用している場合は、クラウドプロバイダー側のノードイメージ更新ステータスを確認し、未対応の場合はノードプールローテーションでパッチ適用済みイメージへ置換する手順が一般的です。

自社カーネルの脆弱性判定に利用する非破壊検証スクリプトの実例

コミュニティから公開されている非破壊検出スクリプト(github.com/rootsecdev/cve_2026_31431内のtest_cve_2026_31431.py)は、システムバイナリや/etc/passwdといった重要ファイルには一切手を触れず、一時ディレクトリ内に作成したセンチネルファイルのみで脆弱性の有無を判定する設計となっています。スクリプト本体はPython 3.10以上の標準ライブラリのみで動作し、socket、os、zlibといった追加依存ゼロのモジュールで構成されているため、本番環境でも安全に実行できる点が特徴です。

具体的には、4KiBのセンチネルファイルを一時ディレクトリに作成してページキャッシュへロードし、AF_ALGソケットとauthencesn(hmac(sha256),cbc(aes))が呼び出し可能であることを確認した上で、splice経路を使用したscratch writeを試行します。実行コマンドと終了コードの意味は次のとおりです。

python3 test_cve_2026_31431.py

終了コード0は脆弱でない(または前提条件を満たさない)状態、終了コード2は脆弱性が確認された状態、終了コード1はテストエラーを示します。検出器は終了時に作成したセンチネルファイルを必ず削除する設計のため、システム整合性への副作用はありません。

ファイル整合性監視を回避する検知困難性とdirty bit挙動の構造的理由

本章ではCopy Failが従来のセキュリティ監視製品やファイル整合性チェックツールを構造的に回避する仕組みを解説します。検知が極めて困難である理由を理解することは、新たな検知設計と監視アーキテクチャの再構築に直結します。

ページキャッシュ書き換えがディスク書き戻しを誘発しない構造的仕組み

Copy Failの最大の隠密性は、ページキャッシュへの書き込みがdirtyビット未設定のまま行われる点にあります。Linuxのページキャッシュは通常、ユーザー空間からwrite()やmmap()経由で書き込みが発生した際にページがdirty状態としてマークされ、後続のwriteback処理によって物理ディスクへ反映される仕組みになっています。Copy Failの場合、authencesnのscratch writeはカーネル内部のscatterwalk経路を通って直接ページに書き込まれるため、dirtyマーキングがバイパスされる動作です。

この結果、ディスク上のファイルは全く変更されないまま、メモリ上のページキャッシュだけが書き換わる状態が成立します。ファイル実行時にカーネルが参照するのはページキャッシュであるため、攻撃者が書き換えた内容は即座に実行に反映される一方で、ディスクからファイルを再読み込みすると元の正規バイナリが復元される現象が発生します。この非対称性が「メモリ上のファイルとディスク上のファイルが乖離する」異常状態を作り出し、フォレンジック調査においてもページキャッシュをダンプしない限り痕跡を発見できない構造が形成される結果です。

AIDE・Tripwire等のチェックサム比較が機能不全に陥る原因

AIDE、Tripwire、Samhainといった代表的なファイル整合性監視(FIM)ツールは、システムバイナリのSHA256やSHA512チェックサムを定期的に計算し、ベースラインと比較することで改竄検知を行う仕組みです。Copy Failに対してこれらのツールが無力化される理由は、チェックサム計算がread()システムコールを通じてファイルを読み込む際、カーネルがページキャッシュではなくディスクからの再読込を行わないためです。

FIMツールが対象ファイルをopenしてreadした場合、カーネルはまずページキャッシュの存在を確認し、キャッシュ済みであればその内容を返します。攻撃者がページキャッシュを書き換えた直後はFIMツールの読み込みも改竄後データを取得するため、ベースラインと比較すれば差分が検知されるはずです。しかし問題は再起動やドロップキャッシュ操作後で、その時点でディスクから再読込された正規バイナリが新たなページキャッシュとして登録され、FIMツールは「正常」と判定する状態に戻ります。攻撃者がアクセスを継続している間だけ改竄が有効である「揮発性改竄」の性質が、ベースライン管理型FIMの検知ロジックを根本から無効化します。

inotify・fanotifyでファイル変更イベントが発火しない構造

inotifyとfanotifyはLinuxカーネルが提供するファイルシステムイベント通知機構であり、IN_MODIFY、IN_ATTRIB、FAN_MODIFYといったイベントでファイル変更を検知できます。しかしこれらの機構は、VFS(Virtual File System)層のwrite系操作に対してフックする設計となっており、scatterwalk経由の直接ページキャッシュ書き込みではイベントが発火しません。Copy Failはこの構造的盲点を完全に突いた攻撃となっています。

セキュリティ製品の多くがinotify/fanotifyベースのリアルタイムファイル監視を採用しているため、setuidバイナリの改竄が発生してもアラートが上がらない状態が常態化します。auditdのファイルアクセス監査(-w /usr/bin/su -p wa)も同様にVFS層のシステムコール監査に依存しているため、splice経路でのカーネル内部書き込みは監査ログに記録されません。検知側はファイル変更の事実そのものを観測できないため、AF_ALGソケット作成や異常なsplice呼び出しといった「攻撃の前段階」を捉える間接的な検知設計へ移行する必要が生じています。

メモリ常駐改竄とリブート後の状態消失による証跡欠損の運用リスク

Copy Failによる改竄はメモリ常駐型であり、システム再起動でページキャッシュが揮発するため改竄状態は自然に消失します。攻撃者にとってはこれが追跡回避の利点となり、防御側にとっては「インシデント発生時に証跡を保全できない」運用リスクとして機能します。インシデントレスポンスにおいて再起動はトラブルシューティングの常套手段となっていますが、Copy Fail被害の疑いがある場合は再起動前にメモリダンプを取得することが鉄則です。

具体的には、LiME(Linux Memory Extractor)や/proc/kcore経由のメモリ取得、もしくはAVMLによるユーザー空間からのフルメモリダンプを実施し、Volatility等のフォレンジックツールで解析する手順が推奨されます。さらに対象setuidバイナリのページキャッシュをdrop_caches直前に物理ディスクから再読込せず保全することも重要であり、運用部門とセキュリティ部門の連携プロセスを事前定義しておくことが現実的な対応として求められます。

既存エンドポイント保護製品の検知失敗パターンと現実的事例分析

既存のエンドポイント保護製品(EDR/EPP)が抱える検知の盲点は、以下の複数パターンに分類されます。Copy Failを主軸に据えた検知設計を行う際は、これらの失敗パターンを認識した上で多層防御を組み立てる必要があります。

• ファイル整合性監視:再起動後のチェックサム比較で「正常」と判定される
• VFSイベント監視:inotify/fanotifyにイベントが届かない
• auditdファイル監査:-w監視でwriteシステムコールが記録されない
• 署名ベース検知:ページキャッシュ内の改竄を読み取る経路が存在しない
• 振る舞い検知:setuid実行は通常運用と区別困難で誤検知抑制が効きすぎる
• ネットワーク監視:LPEはネットワーク通信を発生させないため検知不能
• プロセス監視:su実行自体は正常な操作として日常的に発生

現実的な検知設計は、AF_ALGソケット作成イベント(socket(2)のAF_ALGドメイン指定)、authencesnバインド(bind(2))、splice/vmsplice呼び出しの異常パターンといった「攻撃チェーン上流の挙動」をeBPFやauditdで捕捉する方向にシフトしつつあります。最終的な改竄結果ではなく攻撃成立に至るカーネルAPI呼び出しシーケンスを監視対象とする発想転換が、Copy Fail以降のEDR設計トレンドとして定着しつつある状況です。

コンテナ脱出・Kubernetesノード侵害への二次被害連鎖と防御設計

本章ではCopy Failが単一ホストの権限境界を超え、コンテナ脱出およびKubernetesノード全域への侵害連鎖を引き起こす技術的構造と、各層における防御設計を解説します。マルチテナント環境やコンテナオーケストレーション基盤の運用責任者にとって特に重要な内容です。

ホスト共有ページキャッシュが招くコンテナ境界突破の発生原理と仕組み

Linuxコンテナの分離はnamespaceとcgroupによるリソース論理分割で実現されていますが、ページキャッシュ自体はホストカーネル単位で全プロセスに共有される設計となっています。これは性能最適化の観点では合理的であり、同一ファイルを複数コンテナが読み込む際にメモリ消費を抑制する効果を持ちます。一方Copy Failの観点では、コンテナ内から発行された攻撃がホスト全体のページキャッシュに到達できる構造的脆弱性として機能してしまう設計です。

具体的には、攻撃者制御下のコンテナ内プロセスがAF_ALGソケットを作成し、コンテナ内から見えるファイル(コンテナイメージ内の/usr/bin/su等)に対してsplice攻撃を発行した場合、書き込まれるページキャッシュはホストカーネルが管理する共有領域です。同一ホスト上の別コンテナが同じファイルを実行した瞬間、そのコンテナでも改竄バイナリが実行され、別コンテナ内でroot権限が奪取されます。コンテナ分離の前提が暗号サブシステムの共有によって突破される、典型的な「分離の不完全性」が露呈した事例となっています。

1つのPod侵害からKubernetesノード全域に波及する被害連鎖

Kubernetes環境におけるCopy Failの被害連鎖は、単一Pod侵害から同一ノード上の全Podへ、さらにノード上で動作するkubeletやコンテナランタイム(containerd、CRI-O)の特権プロセスへ、最終的にノード全体の制御権奪取まで段階的に拡大する性質を持ちます。攻撃の起点は侵害された単一Podで十分であり、追加の脆弱性チェーンを必要としません。

侵害連鎖が成立する技術的根拠は、Kubernetesノード上の全Podが同一カーネル・同一ページキャッシュを共有している構造にあります。攻撃者はホスト上の/usr/bin/su、kubelet実行ファイル、containerdバイナリといった特権プロセスのページキャッシュを書き換えることで、それらのプロセスが次に実行されるタイミングで任意コードを動作させられます。kubeletが奪取された場合はノード上の全Podに対する制御が攻撃者の手に渡り、さらにkubelet経由でAPIサーバーへの通信トークンが入手できれば、クラスタ全体への横展開も視野に入る深刻な事態へ発展する重大なシナリオです。

マルチテナント環境における他テナント特権昇格と情報漏洩の現実リスク

マルチテナント型のクラウドサービスやSaaSプラットフォームでは、複数顧客のワークロードが同一Linuxホスト上で稼働する構成が一般的です。Copy Failはこの構成において、悪意ある顧客が自身のテナント境界を超えて他顧客のデータや特権プロセスにアクセスできる経路を開きます。テナント分離をコンテナ・名前空間・cgroupに依存している環境では、Copy Failが事実上の脱出経路として機能してしまう現実があります。

具体的なリスクシナリオとして、CI/CDサービス上で他顧客のビルドジョブが残したシークレットを参照する、SaaSデータ処理基盤で他テナントのデータベース認証情報を奪取する、共有ホスティングサービスで他ユーザーのウェブアプリを書き換えるといった事象が想定されます。クラウドプロバイダー各社はカーネルパッチ適用を最優先で進めていますが、適用完了までの暫定期間においては、テナント側でも自身のワークロード内でAF_ALGをseccomp等で遮断する自衛策を講じることが推奨されます。

seccompプロファイルでAF_ALGソケット作成を遮断する防御策

コンテナ内からのCopy Fail攻撃を遮断する効果的な手段は、seccomp(secure computing mode)プロファイルでAF_ALGソケットの作成を禁止する方法です。socket(2)システムコールの第1引数(domain)としてAF_ALG(値0x26)が指定された呼び出しを拒否することで、コンテナ内プロセスはAF_ALGインターフェースに到達できなくなり、攻撃チェーンの起点が物理的に遮断されます。

具体的なseccompプロファイル設定例として、Dockerコンテナ実行時に以下のような呼び出し制限を加える運用が推奨されます。

{"syscalls":[{"names":["socket"],"action":"SCMP_ACT_ERRNO","args":[{"index":0,"value":38,"op":"SCMP_CMP_EQ"}]}]}

KubernetesではsecurityContext.seccompProfileフィールドでカスタムプロファイルを指定でき、Pod単位での適用が可能です。AF_ALGはコンテナ内で必要となるケースが極めて稀であるため、デフォルト設定として遮断しても業務影響はほぼ発生しないと考えられます。containerd/CRI-Oの上位レイヤーでもPod Security Standardsの「restricted」プロファイル準拠で同等の効果が得られます。

gVisor・Kata Containers併用による多層防御の判断基準

seccompによる遮断が運用上採用できない環境では、gVisorやKata Containersといった分離強化型コンテナランタイムの併用が有効な多層防御策となります。両者は異なるアプローチでコンテナ分離を強化しており、適用判断は要件と性能影響のトレードオフで決定されます。

選定の基本軸は「untrusted codeを多数同時実行するか」「性能要件がどれほど厳しいか」「既存運用基盤との親和性」の3観点となります。AF_ALGをそもそも提供しないgVisorは攻撃面を構造的に削除する効果を持ち、Kata ContainersはCopy Failがホストカーネルに到達する経路自体を遮断する点が特徴です。両者ともseccomp併用で更なる多層防御を実現できる構成として推奨されます。

公式パッチ適用手順とkernel 6.18.22・6.19.12・7.0更新判断基準

本章ではCopy Failの恒久対策である公式カーネルパッチの適用手順と、運用環境別の更新判断基準を整理します。再起動を伴うカーネル更新の実務影響と、無停止パッチ技術の活用判断が中心トピックとなります。

上流コミットa664bf3d603dと安定版バックポート対応の関係性

Copy Failの上流(mainline)修正コミットはa664bf3d603dであり、kernel 7.0系で正式取り込まれました。修正の本質は2017年のin-place最適化(72548b093ee3)を撤回し、algif_aeadのAEAD処理をout-of-place動作に復帰させる方針です。これによりreq->srcとreq->dstが再び独立したscatterlistとして分離され、splice経由のページキャッシュページが書き込み可能なdst側に混入する経路が物理的に遮断されます。

安定版カーネルへのバックポートは2系列で実施されており、6.18.22系はcommit fafe0fa2995a、6.19.12系はcommit ce42ee423e58で対応済みです。Greg Kroah-Hartman名義のlinux-cve-announceメーリングリスト(2026042214-CVE-2026-31431-3d65@gregkh)で公式アナウンスされており、各ベンダーはこれらのコミットを自社の長期サポートカーネルにバックポートして配布する流れが取られています。古いLTS系列(4.14、4.19、5.4等)へのバックポート可否はベンダー個別の判断であり、サポート期間外と判定された場合は暫定回避策に依存する運用が必要となります。

Ubuntu・RHEL・SUSE各ベンダーパッチリリース状況の確認手順

主要ディストリビューションベンダーは2026年4月29日の公開と同時にパッチ提供を開始しており、各社のセキュリティアドバイザリで対象カーネルパッケージが順次公開されている状況です。確認手順はベンダーごとに異なるため、自社環境のディストリビューションに応じた一次ソースを参照する必要があります。

適用判定のポイントは「アドバイザリ番号でCVE-2026-31431が明記されているか」「対象カーネルバージョンが自社環境と一致するか」の2点です。商用サポート契約がある場合はベンダー固有のサポートポータルで個別パッチが提供される場合もあり、特にRed Hatの場合はEUS(Extended Update Support)契約の有無で配布タイミングが異なる点に留意が必要となります。

livepatch・kpatch活用による無停止カーネル更新の適用判断

カーネル更新に伴う再起動が業務継続性の観点で許容できない環境では、livepatchやkpatch等のライブカーネルパッチ機構の活用が有効な選択肢となります。Ubuntu Pro契約のCanonical Livepatch、Red HatのKpatch、SUSEのkGraftはいずれもCopy Fail向けライブパッチを順次提供しており、カーネル再起動なしで脆弱性修正を適用できる仕組みです。

適用判断の基準は「再起動許容ウィンドウの有無」「ライセンス契約の有効性」「対象カーネルバージョンのサポート可否」の3点となります。ライブパッチは恒久対策ではなく次回再起動までの暫定修正である性質を持つため、計画停止時には正規パッケージ更新による恒久パッチ適用が原則として推奨されます。ライブパッチ未対応環境では、暫定的にalgif_aead無効化で攻撃面を遮断しつつ、計画停止枠を確保してパッケージ更新を実施する2段階運用が現実的です。

検証環境での再起動テストから本番カーネル反映までの推奨5ステップ

本番環境へのカーネルパッチ適用は、検証環境での事前テストを経た段階的展開が推奨されます。Copy Fail対応における推奨手順を以下の5ステップに整理します。

1. 検証環境で対象カーネルバージョンへ更新、再起動後のシステム正常性を確認
2. 業務アプリケーション・ミドルウェアの基本動作テスト(暗号処理を含むエンドツーエンド検証)
3. テスト環境でtest_cve_2026_31431.py実行、終了コード0(脆弱でない)を確認
4. ステージング環境で本番同等構成での負荷テスト・回帰テストを実施
5. 計画停止枠で本番環境へ段階適用、ロールバック手順を事前定義した上で実行

各ステップでの検証範囲はシステム特性により調整します。AF_ALGを実際に利用するアプリケーション(一部の暗号化ライブラリやハードウェアアクセラレータ連携プログラム)が存在する場合は、out-of-place動作への切り戻しによる性能影響を負荷テストで確認することが推奨されます。Copy Failパッチは性能的にはin-place最適化の撤回となるため、暗号スループットが要求される環境では事前測定が運用判断に直結する重要事項です。

パッチ適用後のtest_cve_2026_31431.py実行による修正完了確認

パッチ適用後の修正完了確認には、コミュニティ公開の非破壊検出スクリプト(rootsecdev/cve_2026_31431内のtest_cve_2026_31431.py)を再実行する手順が最も確実です。スクリプトは脆弱性が残存している場合のみ終了コード2を返し、修正済みの場合は終了コード0を返す設計のため、自動化されたCI/CDパイプライン上での検証にも組み込みやすい形式となっています。

検証用コマンドの実行例を以下に示します。

python3 test_cve_2026_31431.py; echo "Exit code: $?"

パッチ適用直後はカーネルモジュールの再ロードまたは再起動が必要であり、再起動なしでパッチ反映を試みた場合は古いalgif_aeadモジュールがメモリ上に残存するため、検証スクリプトが脆弱性を継続検知する可能性があります。再起動完了後に上記コマンドを実行し、終了コード0が返ることを確認した時点でパッチ適用完了とみなす運用が標準的です。Configuration Management Database(CMDB)上で対象ホストのパッチステータスを更新し、組織全体の脆弱性管理プロセスとの連動を取ることも推奨されます。

algif_aead無効化による暫定回避策と暗号機能停止の業務影響評価

本章ではパッチ適用が即座に実施できない環境向けの暫定回避策として、algif_aeadカーネルモジュールの無効化手順と、それに伴うアプリケーション影響の評価方法を解説します。緊急対応時の判断材料として活用できる内容です。

/etc/modprobe.d設定とrmmodコマンド併用の手順詳細

algif_aeadの暫定無効化は、/etc/modprobe.d配下に設定ファイルを作成しモジュールロードを禁止する設定と、現在ロード中のモジュールをrmmodで強制アンロードする操作の2段階で完了します。Theori公式の推奨手順は次のコマンド列です。

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

1行目のmodprobe設定は、システム起動時や他モジュールからの依存解決時にalgif_aeadのロードを試行された際、/bin/falseを実行してロードを失敗させる仕組みです。2行目のrmmodは現在ロード済みのモジュールを即座にアンロードします。設定後はtest_cve_2026_31431.pyを実行し、Precondition not metが表示されて終了コード0が返ることを確認します。再起動を伴わずに即時防御効果が得られる点が、緊急対応として広く採用されている主要因です。

algif_aead無効化が影響するユーザー空間暗号処理の具体的な範囲

algif_aead無効化は暗号処理全般を停止する操作ではなく、影響範囲はユーザー空間からAF_ALGソケット経由でAEADアルゴリズムを呼び出す特定の処理に限定されます。具体的には以下の用途が機能停止の対象となります。

• cryptodevや独自設計のユーザー空間暗号ライブラリでAF_ALG AEADを利用するアプリケーション
• ハードウェア暗号アクセラレータをAF_ALG経由で呼び出すソフトウェア
• 特定の組み込みLinuxファームウェアでAF_ALG AEADに依存する処理
• 一部のVPN製品でAF_ALG AEADを利用する暗号処理パス
• AEADベンチマークツールや暗号ライブラリのテストスイート

一方、Linuxサーバーで一般的に稼働する暗号処理の大半は、AF_ALG経由ではなくOpenSSL、libgcrypt、Botan等のユーザー空間ライブラリで完結するため、algif_aead無効化の影響を受けません。事前確認の方法として、auditdで30分から1時間程度AF_ALGソケットのbind呼び出しを監査し、実際に呼び出すプロセスが存在するかを確認する手順が推奨されます。

dm-crypt・LUKS・kTLS・IPsec・OpenSSL・SSHへの影響有無

運用上の懸念が強い主要暗号機能について、algif_aead無効化の影響有無を整理します。多くの一般的な暗号処理は影響を受けず、運用継続性に支障が出ない点が確認されています。

表のとおり、algif_aead無効化はディスク暗号化、TLS通信、IPsec VPN、SSH接続といった主要機能を一切阻害しません。これらの機能はカーネル内部の暗号API(crypto/aead.c等)を直接呼び出すか、ユーザー空間で暗号処理を完結させる設計となっており、AF_ALGソケットインターフェースを経由しないためです。Copy Fail対応における暫定無効化の決定が、運用継続性の観点でも採用しやすい根拠がここにあります。

algif_aead暫定対応の限界と恒久パッチ移行までの併用運用方針

algif_aead無効化は緊急対応として極めて有効ですが、恒久対策ではない点を明確に認識して運用する必要があります。限界として認識すべき主要事項は、第一に他モジュールへの将来的な脆弱性発見への耐性がない点、第二にカーネル再起動時の設定永続化の確認が必要な点、第三に後続のセキュリティパッチで関連する変更が入った場合の互換性です。

併用運用の基本方針は、暫定無効化を即時実施した上で、計画停止枠を確保してパッチ適用に移行する2段階アプローチです。具体的には、1段階目で全本番環境にalgif_aead無効化を緊急展開し、2段階目で検証環境でのパッチテスト完了後、優先度の高いマルチテナント環境やCI/CDサーバーから順次カーネル更新を実施します。最終ステップとして、パッチ適用完了後に/etc/modprobe.d/disable-algif-aead.confを削除しalgif_aeadを再有効化することで、本来のシステム機能を復元します。

モジュール無効化失敗時のフォールバック手順と再有効化トリガー管理

rmmod algif_aeadが「Module algif_aead is in use」エラーで失敗するケースが存在し、この場合は依存モジュールの確認と段階的アンロードが必要です。失敗時のフォールバック手順を以下に整理します。

1. lsmod | grep algif_aeadで使用中プロセス・依存モジュール数を確認
2. fuser /dev/cryptoまたはss -xpaで AF_ALGソケット利用プロセスを特定
3. 該当プロセスの停止または再起動を計画的に実施
4. 再度rmmod algif_aeadでアンロード試行、成功したらmodprobe.d設定を反映
5. 失敗が継続する場合はカーネル再起動でクリーンな状態から無効化を適用

再有効化のトリガー管理も運用設計上重要となります。パッチ適用完了の自動検出後、Configuration Management(Ansible、Chef、Puppet)で/etc/modprobe.d/disable-algif-aead.confの削除と必要に応じてmodprobe algif_aeadの実行をオーケストレーションする設計が推奨されます。手動運用の場合は、パッチ適用記録と暫定無効化解除を紐づけたチケットフローで管理ミスを防止する体制が求められる対応です。

CI/CDランナー・マルチテナント環境における優先対処順位の判断軸

本章ではCopy Failの被害リスクが構造的に高い環境カテゴリを整理し、組織内の優先対処順位を決定するための判断軸を提示します。リソースが限られる現場での対応戦略策定に直結する内容です。

GitHub Actions・GitLab Runner・Jenkinsの優先対処序列

CI/CDランナー環境はCopy Failの最優先対処カテゴリに該当します。理由は明確で、これらの環境では信頼できないコードを日常的に実行するワークロード特性があり、攻撃者が悪意あるリポジトリやプルリクエストを通じてビルドジョブ内に攻撃コードを混入させる経路が常に開かれているためです。優先対処序列を以下に整理します。

1. セルフホスト型ランナー(自社管理サーバー上で稼働)を最優先で対応
2. 共有ランナーで複数プロジェクトが同一ホストを利用する構成を次優先
3. マネージド型でも信頼境界外のコードを実行する環境(Public CI)を高優先
4. 専用ランナーで信頼済みコードのみ実行する環境を中優先
5. 使い捨て型ランナー(ジョブごとに新規VM起動)を低優先で対応

セルフホスト型ランナーの危険性が突出する理由は、ホストOSがランナー実行間で再利用される構成が一般的であり、Copy Fail攻撃で書き換えられたページキャッシュが後続ジョブにも影響する継続性を持つためです。GitHub Actions self-hosted runner、GitLab Runnerのshell executor、Jenkinsのagent常駐構成はいずれもこの問題に直面しており、即時パッチ適用または使い捨て化への構成変更が強く推奨されています。

共有ビルドサーバーでuntrusted codeを実行する環境の危険度

大学の研究室、オープンソースプロジェクトのビルドサーバー、社内の共有開発環境など、複数ユーザーが同一Linuxホストでビルドや実験を行う環境はCopy Failの直接的な攻撃対象として高い危険度を持ちます。これらの環境では、ある利用者が別の利用者に対してroot権限の奪取を試みる動機と機会が両方とも揃いやすく、内部者脅威への耐性が著しく低下します。

具体的なリスクシナリオとして、研究室の共有計算サーバーで悪意ある学生が他研究員の実験データを破壊または窃取する、社内開発サーバーで権限境界を超えた他チームのソースコード改竄を行う、共有ホスティングサービスで他顧客のウェブサイトを書き換えるといった事象が想定されます。これらの環境への対応は、パッチ適用と並行してユーザー単位のリソース分離強化(Linuxユーザー名前空間活用、firejail等のサンドボックス導入)を検討することが現実的な対策として位置づけられる方針です。

クラウドプロバイダー・SaaSベンダー側の責任範囲と対応状況

主要クラウドプロバイダー(AWS、Google Cloud、Microsoft Azure)はCopy Fail公開直後から自社マネージドサービスのパッチ適用を進めており、各社のセキュリティブログやステータスページで対応状況が公開されています。責任共有モデル(Shared Responsibility Model)の観点では、ホストOSのカーネルパッチ適用はクラウドプロバイダー側の責任範囲となるケースが大半です。

具体的にはマネージドKubernetes(EKS、GKE、AKS)、サーバーレス(Lambda、Cloud Run、Azure Functions)、マネージドDB(RDS、Cloud SQL、Azure SQL)といったサービスでは、プロバイダー側で自動的にパッチ適用が実施されます。一方、IaaS型(EC2、Compute Engine、Azure VM)で顧客が管理するLinux仮想マシンについては、顧客側でカーネル更新を実施する責任範囲となるため、責任共有モデルを正確に把握した上で対応漏れがないかを確認する作業が組織内で求められます。

ジャンプサーバー・開発用共有ホストにおける即時対応と優先度の判断軸

ジャンプサーバー(踏み台サーバー)や開発用共有ホストは、Copy Fail対応において優先度判定が分かれる環境です。判断軸として「ログイン可能な利用者の信頼性」「サーバー上で実行されるコードの種別」「侵害された場合のブラスト半径(他システムへの影響範囲)」の3点を評価します。判断結果が不明確な場合は、原則として最優先カテゴリとして扱うことが安全側の選択肢となります。

ジャンプサーバーは複数の本番システムへのアクセス経路となる性質上、ここでroot権限が奪取された場合のブラスト半径は組織全体に及びます。SSH秘密鍵やアクセストークンが踏み台上で管理されている構成では、Copy Fail成功と同時に大規模なクレデンシャル漏洩へ直結する重大事態となります。即時対応の判断基準は、業務影響を最小化しつつパッチ適用を48時間以内に完了させる計画停止枠の確保が現実的なラインとして位置づけられる対応です。開発用共有ホストでも同様の評価軸を適用し、優先度の高い順から段階的に対処を進める運用が推奨されます。

パッチ適用完了までの暫定停止判断とサービス継続性のトレードオフ

Copy Fail対応において、極めてリスクが高いと判断される環境ではパッチ適用完了までサービスを暫定停止する選択肢も検討対象となります。判断基準は「サービス停止時の事業損失」と「侵害発生時の損害想定」の比較衡量であり、後者が前者を上回る環境ではフェイルセーフの原則として停止判断が合理的です。

具体的な判断シナリオとして、信頼できない第三者コードを実行する研究用共有計算機、外部委託先がアクセスする中継サーバー、個人情報を扱うマルチテナントSaaSの一部機能などが該当します。完全停止が現実的でない場合は、機能単位での部分停止(AF_ALG利用機能の無効化、外部からのSSH接続停止等)による段階的リスク低減も有効な選択肢となります。経営層への影響説明資料として、Copy Failの脅威度(決定論的root奪取・コンテナ脱出可能・既存EDRで検知困難)を定量的に整理し、暫定停止の合理性を共有するプロセスが運用上重要な要件です。

AF_ALGソケット監視・auditd活用による侵害検知ログ設計の実務

本章ではCopy Fail攻撃の成立を検知するための監視ログ設計を、auditdを中心とした実装可能な構成として解説します。従来のファイル整合性監視が無効化される環境下で、攻撃チェーン上流の挙動を捉える設計思想が中心テーマです。

auditdルール設定によるAF_ALGソケット作成イベントの捕捉

auditdはLinuxカーネルの監査サブシステム(audit subsystem)と連動し、システムコール単位でのイベントログ記録を実現するツールです。Copy Fail検知の中核は、AF_ALGソケット作成のシステムコールを捕捉するルール設定であり、socket(2)システムコールの第1引数(domain)としてAF_ALG(値0x26 = 38)が指定された呼び出しを監査対象とします。

具体的なauditdルール設定例を以下に示します。

-a always,exit -F arch=b64 -S socket -F a0=38 -k AF_ALG_SOCKET

このルールは64ビットシステム上でsocketシステムコールが第1引数38(AF_ALG)で呼び出された全イベントを「AF_ALG_SOCKET」キーで記録します。/etc/audit/rules.d/copyfail.rulesに保存しaugenrules –loadで反映する運用が標準的です。AF_ALGソケット作成は通常運用ではほぼ発生しないため、本ルールでログが記録された場合は調査対象として優先順位の高いアラートとして扱われます。発生頻度が高い環境では送信元プロセスのexecve情報と紐付けた相関分析が有効となります。

kernel logでalgif_aead関連エラー検知に必要な監視項目

カーネルログ(dmesg、journalctl -k、/var/log/kern.log)にはalgif_aeadモジュール関連のエラーや異常挙動が記録される可能性があり、攻撃試行の痕跡として活用できます。SIEM連携で監視すべき主要項目を以下に整理します。

• algif_aead関連のbind失敗・操作エラーメッセージ
• HMAC検証失敗(authencesnの偽造暗号文に対するエラー応答)の頻発
• scatterwalk_map_and_copy周辺のWARN_ONやkernel oops
• splice/vmsplice呼び出し失敗の異常パターン
• setuid binary実行時のSegmentation faultやIllegal instruction発生
• 不審なAF_ALGソケットbind試行のレート異常
• ページキャッシュ不整合に関連するfilesystem warning

個別ログ単体では誤検知が発生しやすいため、AF_ALGソケット作成→splice呼び出し→HMAC検証失敗→setuid binary実行という一連のシーケンスとして検出する相関ルール設計が推奨されます。SIEM側でのCorrelation Search設定により、5分から10分程度の時間窓内で複数イベントが順序通り発生した場合のみアラート発報する仕組みが実用的な精度を実現します。

setuid binary改竄を運用検知するためのメモリ整合性検証

従来のファイル整合性監視がCopy Failに対して無効化される現状において、メモリ上のページキャッシュ自体を検証する新たな手法が注目されています。具体的には、setuidバイナリのページキャッシュ内容と物理ディスク上のファイル内容を定期的にハッシュ比較し、両者が一致しない場合に改竄を検出するアプローチです。

実装方法として、対象setuidバイナリ(/usr/bin/su、/usr/bin/sudo、/usr/bin/passwd等)をmmap()で読み取りつつ、別途O_DIRECTフラグでopen()してディスクから直接読み込み、両者のSHA256ハッシュを比較するスクリプトをcronで定期実行します。両ハッシュが乖離した場合は、ページキャッシュ改竄が発生している強い兆候となります。1時間から数時間間隔での定期チェックがバランスの良い運用設計であり、検出時はメモリダンプ取得と該当ホスト隔離を自動化することでインシデント対応時間を短縮できる仕組みです。

SIEM連携による異常な暗号API使用パターンの検知設計と実装例

SIEM(Security Information and Event Management)製品との連携により、Copy Fail攻撃の検知精度を組織横断的に向上させることが可能となります。Splunk、Elastic Security、Microsoft Sentinel、QRadar等の主要SIEMでは、auditdログの取り込みと相関分析機能を活用した検知ルール構築が現実的な選択肢となっています。

検知設計の基本パターンは「AF_ALGソケット作成」「authencesnバインド」「splice呼び出し」「HMAC失敗」「setuid実行」の5要素を時系列で相関させるルールです。各要素単独では誤検知率が高いため、最低3要素が同一プロセスツリー内で順序通り発生した場合のみアラート発報する設計が推奨されます。Sigmaルール形式での共有も進んでおり、コミュニティ提供の検知シグネチャを取り込むことで自社実装の負担を軽減できる体制が整いつつあります。MITRE ATT&CKフレームワーク上ではT1068(Exploitation for Privilege Escalation)およびT1611(Escape to Host)へのマッピングが該当する攻撃カテゴリです。

eBPFベース可観測性ツール活用と従来型audit併用の検知設計

eBPF(extended Berkeley Packet Filter)はカーネル空間で安全に検査コードを実行できる仕組みであり、auditdより低オーバーヘッドかつ高粒度な監視を実現します。FalcoやTetragon、Tracee等のeBPFベース可観測性ツールは、AF_ALGソケット作成やsplice呼び出しといった攻撃チェーン上流のシステムコールを高精度で捕捉でき、Copy Fail検知において強力な選択肢となっています。

Falcoの場合、ルール定義ファイル(falco_rules.yaml)にAF_ALGソケット作成や異常なsplice呼び出しを検知するカスタムルールを追加することで、運用環境に即した検知ロジックを構築できます。eBPFは従来型auditdより低レイテンシかつkernel module不要で動作する利点があり、コンテナ環境やKubernetesでの導入が進んでいます。一方、auditdは長期運用実績とコンプライアンス要件への対応で優位性を持つため、両者を補完的に併用する多層検知設計が現実的なベストプラクティスとして定着しつつある状況です。