Cloudflare が「Copy Fail」Linux 脆弱性への対応を報告

2026 年 4 月 29 日、Linux カーネルのローカル特権昇格脆弱性「Copy Fail」（CVE-2026-31431）が公に発表されました。Cloudflare のセキュリティおよびエンジニアリングチームは、この脆弱性が発表された直後から評価を開始しました。私たちは攻撃手法をレビューし、インフラ全体における暴露範囲を評価するとともに、既存の振る舞い検知機能（behavioral detections）が数分以内に攻撃パターンを特定できることを検証しました。 Cloudflare の環境への影響はなく、顧客データのリスクもありませんでした。また、どの時点でもサービスの中断は発生していません。私たちの準備がいかに功を奏したかについては、以下をご覧ください。 背景 Linux カーネルのリリースプロセス Cloudflare は 330 カ所にデータセンターを構える大規模なグローバル Linux サーバーインフラを運用しています。この膨大な量での更新を効果的に管理するため、コミュニティが提供する長期サポート（LTS）バージョンをベースにカスタム Linux カーネルビルドを維持しています。特定の時点では、6.12 や 6.18 など、複数の異なるシリーズから LTS バージョンを利用しており、これらは拡張された更新期間の恩恵を受けています。 コミュニティは定期的にセキュリティおよび安定性アップデートをマージしてリリースしており、これにより自動化されたジョブが約毎週新しい内部カーネルビルドを生成します。これらのビルドは、グローバル展開前に安定性を確保するため、ステージングデータセンターでテストされます。リリースに成功した後、Edge Reboot Release (ERR) パイプラインが 4 週間サイクルでエッジインフラの体系的なアップデートと再起動を管理します。当社のコントロールプレーンインフラでは通常、最新のカーネルを採用しており、再起動は特定のワークロード要件に応じてスケジュールされます。 CVE が公知となる頃には、必要な修正はすでに安定版 Linux LTS リリースに数週間前から統合されているのが一般的です。確立された手順により、これらのパッチは既に展開済みとなっています。 「Copy Fail」の公開時点では、当社のインフラの大部分が 6.12 LTS バージンを稼働しており、一部のマシンでは新しい 6.18 LTS リリースへの移行が始まっていました。 Copy Fail 脆弱性について 対応策の話に入る前に、この脆弱性の概要を理解しておくことが役立ちます。包括的な解説は、元の Xint Code の公開ポストで見つけることができます。 AF_ALG とカーネル暗号化 API Linux カーネルの内部暗号化 API は、kTLS や IPsec などの機能を管理しています。ユーザー空間プログラムは AF_ALG ソケットファミリーを介してこの API にアクセスし、特権を持たないプロセスが暗号化や復号化のリクエストを行うことを可能にします。algif_aead モジュールは、認証付き暗号化（AEAD）暗号に対してこれを支援します。 特権を持たないプログラムは以下の手順に従います： AF_ALG ソケットを開き、AEAD テンプレートにバインドする。 キーを設定し、リクエストソケットを受け入れる。 sendmsg() または splice() を介して入力データを提出する。 recvmsg() を使用して操作を実行する。 ここで splice() システムコールが重要となります。これはページキャッシュ参照を渡すことでデータ移動を行うためです。 メモリメカニズム：ページキャッシュとインプレイス暗号化 ページキャッシュはファイルコンテンツ用の共有システムキャッシュです。setuid バイナリに属するページを修正することは、そのページが削除されるまで、すべてのユーザーに対してそのプログラムを編集することと同義となります。 暗号化 API は散乱リスト（scatterlists）を利用します。これはさまざまなメモリページをリンクする構造体です。2017 年、algif_aead はインプレイス操作のために最適化され、宛先ページと参照ページが連結されました。この設計には、アルゴリズムが意図した境界を超えて書き込まれるのを防ぐための強制力が欠けていました。 脆弱性：境界外書き込み ユーザーが recvmsg() を実行すると、カーネル内の authencesn ラッパーが正当な出力領域の先頭から 4 バイト先へ書き込みを行います： scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1); splice() を使用することで、攻撃者は対象ファイルのページキャッシュページを scatterlist にチェーンできます。これにより境界外書き込みが発生し、キャッシュされたファイルが汚染されることで、攻撃者がどのファイルを修正するか、オフセット、および書き込まれる特定の 4 バイトを制御できるようになります。つまり、このエクスプロイトを用いて以下の項目を操作可能です: ファイル：読み取り可能な任意のファイル。 オフセット：assoclen および splice パラメータを通じて調整可能。 値：sendmsg() 内の AAD バイト 4-7 を介して制御可能。 エクスプロイトの手順 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5uqfOddH7biQaTjtgQOist/5c16c08bf3e5ce2f9030d6f98d2403cb/BLOG-3308_2.png) デフォルトのエクスプロイトは、ほぼすべてのディストリビューションに存在する setuid-root バイナリである /usr/bin/su を標的とします。 キャッシュ参照：/usr/bin/su を O_RDONLY で開き read() を実行してページキャッシュを充填します。その後、ファイル記述子に対して splice() を実行し、これらのページキャッシュ参照を暗号化用の scatterlist に渡します。 セットアップ：AF_ALG ソケットを作成し、authencesn(hmac(sha256),cbc(aes)) に bind() し、キーを設定して特権なしでリクエストソケットを受け入れます。 書き込み構築：各 4 バイトのシェルコードチャンクに対して: AAD バイト 4–7 にシェルコードを含む状態で sendmsg() を実行します。 バイナリをパイプを経て AF_ALG ソケットに splice() し、assoclen + cryptlen が目的の .text オフセットを指すように設定します。 トリガー：recvmsg() が復号化を開始する。authencesn はスクラッチデータを /usr/bin/su のページキャッシュ内のターゲットオフセットに書き込む。関数は -EBADMSG を返すものの、4 バイトの書き込みはすでにグローバルなページキャッシュ内に存在している。 実行：execve("/usr/bin/su") を実行すると、汚染されたページキャッシュが読み込まれる。バイナリが setuid-root であるため、注入されたシェルコードはルート権限で実行される。 アップストリームの修正（コミット a664bf3d603d）は、2017 年のインプレース最適化を元に戻し、このエクスプロイトを無効化する。 私たちの対応 脆弱性が公開された際、多くの作業が並行して開始されました： 爆発範囲のマッピング：セキュリティチームはカーネルエンジニアと連携し、どのカーネルバージョンが脆弱であるかを特定し、潜在的な暴露を評価しました。 カバレッジの検証：セキュリティ担当者がエクスプロイト手法を検討し、承認された内部検証中に既存の振る舞いベースの検知機能がエクスプロイトパターンを識別できることを確認しました。 能動的な脅威ハンティング：セキュリティチームは、脆弱性が公に知られる前に悪用された兆候がないか調査を開始し、全 fleet 規模のログを過去 48 時間遡って検索しました。 緩和策の実装：カーネルエンジニアは、生産サービスに影響を与えずに fleet を保護するランタイム緩和策の開発を開始しました。 ソフトウェア更新の継続：エンジニアリングチームは、更新された Linux カーネルの提供に取り組んでおり、これにはサーバー全体での慎重な再起動と展開が必要でした。 この対応のどの段階においても、顧客への影響はありませんでした。 検出カバレッジの確認 セキュリティチームがまず行ったことの 1 つは、既存のエンドポイント検知がこの攻撃を捕捉できることを確認することでした。当社のサーバーは、プロセス実行パターンを継続的に監視する行動検知を実行しています。これは特定の脆弱性に関する知識に依存するものではなく、ファーム全体における異常な動作を検出します。 エンジニアが対応の一環として内部でこの脆弱性を検証した際、検知プラットフォームは数分以内にこれを警告しました。システムはスクリプトインタープリターから始まり、カーネルの暗号化サブシステムを経て、特権昇格バイナリに至るまでの実行チェーン全体を関連付け、ファーム全体の行動パターンに基づいて悪意のあるものとしてフラグを立てました。 これはシグネチャの更新もルールの変更も人間の介入もなく行われました。この特定の「コピーファイル」攻撃に対するカスタムロジックを記述する以前から、当社の行動検知カバレッジは存在していました。 この確認が重要だったのは、脆弱性固有のルールを作成する前にすでにカバレッジが存在していたことを意味したからです。 悪用痕跡の探索 エンジニアチームがより標的を絞った対策に移行している間、セキュリティ調査は公開時から継続して実施されていました。これはあらゆる重大な脆弱性に対する当社の標準手順です。 当社のセキュリティチームは、重大な脆弱性に対する対応において、単純かつ明確な原則に基づいて活動しています。それは「他の証拠が出るまで、侵害が既に発生したと仮定する」というものです。調査は、脆弱性が公になる前に悪用が既に実行されていた可能性を前提に開始され、確認または否定するために体系的に作業を進めました。 このエクスプロイト（攻撃コード）は、実行時にカーネルログに特徴的な痕跡を残します。私たちは、脆弱性が公に開示される前の 48 時間にわたる中央集権型ロギングインフラストラクチャ全体で、その痕跡を検索しました。もし世界がこれを知る前に誰かがこれを悪用していたのであれば、必ず検出できていたはずです。 影響を受けたシステムのアクセスログを抽出し、誰がいつ接続し、どのようなコマンドを実行したかを再構築しました。これにより、潜在的に影響を受けたインフラストラクチャ上での対話型アクティビティに関する完全なフォレンジック（捜査）像が得られました。 システムバイナリが改ざんされていないことを確認し、既知の信頼できるパッケージマニフェストに対して暗号化ハッシュ値を検証し、永続化メカニズムの存在を探り、ネットワーク接続を監査して不審な点がないかを確認しました。結果はすべてクリーンでした。 インシデントのタイムラインと影響 時間 (UTC) イベント 2026-04-29 16:00 Copy Fail の公的開示。 2026-04-29 ~21:00 セキュリティチームとエンジニアリングチームが、インシデント対応プロセスの完全な宣言前に、フリートの暴露状況と緩和オプションの評価を開始。 2026-04-29 22:52 セキュリティチームは、既存の行動検知機能が「Copy Fail」エクスプロイトのパターンをカバーしていることを確認しました。承認された社内検証中、検知システムは数分以内にこの活動をアラートとして検出しました。 2026-04-29 23:01 既存の行動検知機能により、エクスプロイトに類似した活動に対して高重大度のアラートが生成され、当該技術に対する検知カバレッジが確認されました。 2026-04-29（夜間） 最初の対策プログラムがステージングデータセンターへプッシュされました。デプロイプロセスで依存関係の競合が発生したため、対策はロールバックされました。本番システムへの影響はありませんでした。 2026-04-29（深夜） エンジニアリングチームが bpf-lsm ベースの対策プログラムを策定しました。 2026-04-30 03:14 クロスファンクショナルな協力と緊急性を高めるため、セキュリティインシデントが宣言されました。セキュリティチームは、Cloudflare システム上に悪意のある活動が存在しないことを確認するため、歴史的データに対する全フリート規模の脅威ハンティングを実施しました。 2026-04-30（朝） エンジニアリングチームが bpf-lsm ベースの対策プログラムをテストし、本番環境での運用準備を整えました。 2026-04-30 14:25 対策プログラムの調整と Linux パッチの展開を統括するため、エンジニアリングインシデントが宣言されました。 2026-04-30 約 17:00 決定事項：前回の LTS リーン（Long Term Support）の修正済みビルドをリブート自動化を通じて配信する。新しい LTS への移行を加速せず、その間は bpf-lsm に依存する。 技術用語注記: - bpf-lsm (Berkeley Packet Filter - Linux Security Module): Linux カーネルにおけるセキュリティ拡張機能 2026-04-30（午後） Visibility パイプライン（AF_ALG ソケット使用状況の eBPF トレース）を全フラートに展開。これにより、すべての正当な AF_ALG ユーザーの完全な状況を把握可能になりました。 2026-04-30（夜間） bpf-lsm 緩和プログラムが独立したゲートの背後で展開され、フラート全体を完全に緩和しました。以前に脆弱性があったテストノードでのエンドツーエンド検証により、このエクスプロイトがもはや機能しないことが確認されました。 2026-05-04（午前） パッチ適用済みカーネルを用いた再起動自動化プロセスが通常のペースで再開されました。 2026-05-04 以降 今週前半にすでに再起動自動化プロセスを経たサーバーは、手動で再起動してパッチ適用済みカーネルを反映させました。未対応のサーバーについては、通常の再起動自動化プロセスに従って更新されます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7LI0k0FJgbLKzOkSEtYPwW/997234a334b3694c63417fad5810b679/BLOG-3308_3.png) このグラフは、緩和プログラムがインフラストラクチャを通じて進行した様子を示しています。 どのようにしてこれを緩和したのか？ パッチ適用済み Linux カーネルの展開には長い時間がかかるため、再起動を伴わないエクスプロイトの緩和も同時に追求しました。 モジュールの削除 バグは algif_aead カーネルモジュールに存在していました。したがって、単純な対策はこのモジュールを削除し、再読み込みを禁止することでした。 したがって、この緩和策は、脆弱性を特定したセキュリティ研究者による「Copy Fail」の報告書で推奨されたまさにそのものでした。 echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || true Unfortunately removing the module would have impacted software that leverages the kernel crypto API. This meant that we had to figure out a more surgical mitigation. Bpf-lsm ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2VYFKst8aUkkHCaEdb8yQ4/91ad9a855d6185bccd179fcf092ed636/BLOG-3308_4.png) We've already developed and deployed such a tool for this exact scenario: bpf-lsm. Instead of removing the module, this tool leaves it loaded for legitimate users and uses a BPF Linux Security Module program to deny the socket_bind LSM hook for everyone else. This completely blocks the front door for any exploits. A draft of the eBPF program was put together overnight. Team members picked it up the following morning, ran validations, and made it production-ready. The program is fairly straightforward. On every socket_bind call: If the socket family is not AF_ALG, allow the call through unchanged. If the family is AF_ALG, check the calling binary's path against an allow-list of the binaries we know to be legitimate users. If the binary is on the allow-list, allow the bind. Otherwise, deny it. 与えられたマシン上で脆弱性を悪用せずに緩和策が適用されているかを確認するために、Copy Fail の解説記事では以下の 1 ラインを提供しています: python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));' 緩和策が適用されたマシンでは、正常なバインドではなく、PermissionError: [Errno 1] Operation not permitted（または、どの緩和策が有効かによって FileNotFoundError）が発生します。 ロールアウトの実施 強制措置を有効化する前に、既知の内部サービスが正当な AF_ALG ユーザーである唯一のものであることを確認し、誤ってサービス停止を引き起こさないようにしました。fleet 全体でバイナリごとの AF_ALG 使用状況を追跡するために socket() システムコールにフックする prometheus-ebpf-exporter を使用しました。これにはカーネルの変更は不要であり、数時間以内に数十万台のサーバーからの集計データを取得できました。結果として、特定されたサービスが確かに唯一の正当なユーザーであることが確認されました。 したがって、bpf-lsm のロールアウトは意図的に 2 つのステップで段階的に行われました: まず可視化を取得します。salt でゲート制御された ebpf-exporter 設定をプッシュし、メトリック層において既知のサービスが AF_ALG ソケットを作成する唯一のものであることを確認します。 次に強制措置を実行します。別の強制措置用ゲートの背後に bpf-lsm プログラムをプッシュします。 並行して、主要な LTS ラインに対するアップストリームのバックポートがついに利用可能となり、内部の自動化システムがこれに基づいてパッチ適用済みのカーネルを構築しました。 パッチ適用済みカーネルのテストを、ステージングデータセンターにおいて可能な限り早く開始し、その後、フルートへの完全なパッチ適用のためにより長い再起動プロセスを再開しました。 対策とフォローアップ手順 このシナリオには準備していましたが、Cloudflare では常に学び、改善を続けています。改善 Identified した主要領域は以下の通りです: カーネル API 依存関係へのより良い可視化。プロダクションサービス全体でのカーネルサブシステムの使用状況をレビューし、サービスの停止を伴わずにエクスプロイトに対して迅速に対処し続けることができるようにします。 ランタイム対策の強化。bpf-lsm は対策において貴重なツールですが、このツールをさらに改善したいと考えています。これには、より高速なデプロイメント、より優れたプレイブック、およびツールのログ記録と可視性の向上が含まれます。 Linux カーネルの攻撃対象領域の縮小。カーネル設定の見直しと監査を行い、使用されていないモジュールや機能を事前に特定して、ビルドから完全に削除できるようにします。 結論 「Copy Fail」脆弱性は、私たちにとって独自の課題を提示しました。2 週間に一度の Linux パッチ更新という慣行を続けてきたにもかかわらず、主要な修正が本番カーネルラインにバックポートされるまで約 1 ヶ月を要したため、依然として脆弱な状態にありました。それでも、バックポートリリースから数時間以内にパッチ適用済みカーネルを展開することができました。その間、bpf-lsm は再起動を必要としない精密な緩和策を提供し、私たちのファリートを保護しました。問題のあるモジュールを無効化しようとした最初の試みは失敗しましたが、本番環境ではなく内部のステージング環境内で安全に失敗したため、この依存関係を特定することができました。 展開が完了する頃には、ファリートのすべてのマシンが、パッチ適用済みカーネル、または許可リストに登録されていないバイナリに対して脆弱なコードパスを拒否する bpf-lsm プログラムのいずれかによって保護されていました。このインシデントのどの時点でも顧客への影響はありませんでした。私たちは、今後同様の事態が発生した際に、対応をより迅速にし、可視性を高めるために、上記のフォローアップ作業にコミットしています。責任ある開示は機能し、カーネル内部の可視化ツールはまさにこのような瞬間においてその価値を発揮します。また、bpf-lsm は引き続き、ランタイムにおけるカーネル緩和のために私たちが持つ最も有用なプリミティブの一つであり続けています。 Cloudflare では、重大な脆弱性への対応は、セキュリティ、エンジニアリング、プロダクト、および多くの他のチームにわたる協調的な取り組みです。Ali Adnan、Ivan Babrou、Frederik Baetens、Curtis Bray、Piers Cornwell、Everton Didone Foscarini、Rob Dinh、Elle Dougherty、Kevin Flansburg、Matt Fleming、Kimberley Hall、Brandon Harris、Jerry Ho、Oxana Kharitonova、Marek Kroemeke、Fred Lawler、James Munson、Nafeez Nazer、Walead Parviz、Miguel Pato、Evan Pratten、Josh Seba、June Slater、Ryan Timken、Michael Wolf、Jianxin Zeng ならびに、Copy Fail の調査、緩和、修復に貢献したすべての関係者へ心から感謝申し上げます。また、迅速な対応を可能にした Linux のアップストリームメンテナおよび Copy Fail の研究者の方々にもお礼を申し上げます。

Cloudflare が「Copy Fail」Linux 脆弱性への対応を報告

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト