Copy Fail脆弱性にCloudflareがどう立ち向かったか

Copy Fail脆弱性にCloudflareがどう立ち向かったか

2026年4月29日、Linuxカーネルにローカル権限昇格をもたらす脆弱性「Copy Fail（CVE-2026-31431）」が公開された。この脆弱性を悪用すれば攻撃者はroot権限を取得でき、多くのサーバが影響を受け得る深刻なものだ。

Cloudflareは世界中の330都市に展開する大規模なLinuxサーバ基盤を運用している。同社は開示直後からセキュリティチームとエンジニアリングチームが動き、既存の振る舞い検知が数分で攻撃パターンを特定できることを確認し、また再起動不要の緩和策としてeBPF LSMを展開した。結果として顧客データへの影響やサービス停止は一切発生していない。

Copy Fail脆弱性（CVE-2026-31431）の全容

Linuxカーネルのcrypto APIには、AF_ALGソケットファミリ経由で一般ユーザプロセスが暗号化・復号を要求できる仕組みがある。ここで問題となったのは「aead」テンプレートを用いるモジュール `algif_aead` の欠陥だ。2017年に導入されたin-place最適化によって、復号時に割り当てられた出力領域を超えた4バイトの書き込みが発生するようになっていた。

攻撃者はまず `splice()` システムコールを使い、`/usr/bin/su` のようなsetuidバイナリのファイル記述子からページキャッシュの参照を暗号化操作のscatterlistにチェインさせる。その状態で `recvmsg()` を呼ぶと、本来許される範囲外の4バイトがターゲットのページキャッシュに書き込まれる。汚染されたバイナリを `execve()` で実行すれば、root権限で任意のコードが動くという筋書きだ。

このエクスプロイトの流れは、Cloudflareのブログで詳述された技術情報と、Xint Codeによる元の開示記事を基にしている。Linuxコミュニティはコミット a664bf3d603d で2017年の最適化を差し戻しており、それが正式な修正となる。

CloudflareのLinuxカーネル管理プロセス

CloudflareはカスタムLinuxカーネルを自前でビルドし、コミュニティの長期サポート（LTS）バージョンをベースにしている。新型カーネルの選定からグローバル展開まで、およそ4週間のサイクルでシステム的なアップデートと再起動を実施している。公開前に既知のセキュリティパッチがマージされるのが常だが、Copy Failの修正はメインラインにマージされてから1ヶ月経っても主要LTSラインへのバックポートが完了していなかった。このタイムラグが生じたため、Cloudflareの大部分のサーバは6.12 LTSカーネルを稼働させており、脆弱性が残る状態だった。

Cloudflareの多層防御：検知から再起動不要の緩和まで

振る舞いベースの検出が数分で作動

Cloudflareのエンドポイントには、プロセスの振る舞いを常時監視する検知プラットフォームが導入されている。特定の脆弱性シグネチャに頼るのではなく、通常とは異なる実行パターンを検出する仕組みだ。専用ルールの更新や人の介入なしに、社内で実施した検証でエクスプロイトの試行が数分以内に悪性と判定され、アラートが発報された。これは攻撃チェーン全体（スクリプトインタプリタ → AF_ALG経由の暗号サブシステム呼び出し → 権限昇格バイナリの実行）を一つの振る舞いパターンとして捉えた結果だ。

脅威ハンティングと過去48時間のログ調査

セキュリティチームは「公開前から悪用されていた可能性を前提にする」という原則に立ち、エクスプロイトが残すカーネルログの痕跡を独自の集約ログ基盤で検索した。また、関係するシステムへの全アクセスログを収集し、接続元や実行コマンドを再構成、システムバイナリのハッシュ整合性を検証した。その結果、過去48時間においてCloudflareのインフラ上で悪用された証拠は一切確認されなかった。

eBPF LSMによる緊急緩和の展開

根本対策であるパッチ済みカーネルのロールアウトには時間がかかるため、チームは無効化モジュール `algif_aead` の削除をまず試みた。しかし実際にはレガシーな社内サービスがcrypto APIを利用しており、削除すると障害を招くことがステージング環境のテストで判明した。そこで再起動不要の外科的対策として、BPF Linux Security Module（bpf-lsm）を使ったプログラムを導入した。

# 素朴な緩和（モジュール無効化）は依存関係のため断念
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

bpf-lsmプログラムは `socket_bind` LSMフックにアタッチし、AF_ALGソケットを開こうとするバイナリのパスをホワイトリストと照合する。許可リストにないバイナリからの `bind()` 呼び出しは拒否するため、悪用の入口を完全に封鎖する。このアプローチを採る前に、Prometheus eBPF Exporterを使って艦隊全体のAF_ALG利用実態を可視化し、許可リストに載せるべき正当なサービスが本当に1つだけであることを検証した。

# eBPF LSMプログラムの擬似フロー
- ソケットファミリがAF_ALGでなければ通過
- AF_ALGの場合、呼び出し元バイナリのパスを許可リストと照合
- 許可されていればbindを許可、それ以外は拒否

これにより、大部分のサーバはパッチ済みカーネルが配布されるまでの間、bpf-lsmによって保護された。テスト用ノードで実際にエクスプロイトコードを実行し、PermissionError が返され攻撃が不可能になったことを確認している。

一連の対応から得た教訓と今後の改善

Cloudflareは今回の対応を通じていくつかの改善点を特定した。まず、カーネルAPIの依存関係をより深く可視化し、将来の緊急緩和時にサービス停止を避けられるようにすること。次にbpf-lsm自体の展開速度やログの充実を図り、ランタイム防御の即応性を高めること。さらに、カーネルコンフィギュレーションの監査を進め、使われていないモジュールや機能を事前にビルドから除去することで攻撃対象領域を縮小していく方針だ。

今回のインシデントで、Cloudflareは顧客影響ゼロを達成した。パッチ済みカーネルのリリースとbpf-lsmによるレイヤーが艦隊全体に行き渡り、脆弱性が悪用される余地は残らなかった。Linuxコミュニティの責任ある開示、社内の可視化ツール、そしてbpf-lsmというプリミティブが、迅速な防御を可能にしたといえる。

この記事のポイント

• Linuxカーネルの脆弱性「Copy Fail」はローカルからroot権限を奪取できる深刻な問題
• Cloudflareは公開と同時に既存の振る舞い検知で即座に捕捉し、過去ログの脅威ハンティングで未然悪用がないことを確認
• 再起動不要の緩和策としてeBPF LSMを導入し、AF_ALGソケットへの不正アクセスをホワイトリスト方式で遮断
• 根本パッチのロールアウトと並行して運用し、結果的に顧客データやサービスへの影響は皆無
• 可視化ツール（Prometheus eBPF Exporter）の事前整備が緩和策の意思決定を支えた

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験