1 ポイント 投稿者 GN⁺ 1 시간 전 | まだコメントはありません。 | WhatsAppで共有
  • 非特権ローカルユーザーauthencesnAF_ALGsplice() を連結することで、読み取り可能なファイルに対する ページキャッシュへの4バイト書き込み を実現し、そこから root 権限まで昇格できる
  • カーネルごとのオフセットやレース条件なしに、732バイトの Python スクリプト 1本で複数の Linux ディストリビューション上でそのまま動作し、同じエクスプロイトで root shell を取得できる
  • 影響範囲はパッチ適用前の 主要な Linux ディストリビューションの大半 に及び、デフォルト設定で有効な AF_ALG により 2017 年からパッチ時点まで広く露出している
  • マルチテナントホスト、Kubernetes / コンテナクラスター、CI ランナー、ユーザーコード実行型 Cloud SaaS では、一般アカウントや 1 つの pod がホスト root につながり得るため、優先的なパッチ適用が必要
  • 対応としてはメインラインコミット a664bf3d603d を含む カーネルパッチ が最優先で、パッチ前は algif_aead の無効化と、信頼できないワークロードに対する AF_ALG の遮断 が重要

脆弱性の概要

  • 単線的なロジック欠陥 1 つを authencesnAF_ALGsplice() でつなぐことで、ページキャッシュへの4バイト書き込み に至るローカル権限昇格が可能になる
  • カーネルごとのオフセットやレースウィンドウなしに、732バイトの Python スクリプト 1本で 2017 年以降に配布された Linux ディストリビューション全般で同一に動作する
  • 同じエクスプロイトバイナリが修正なしで複数のディストリビューション上で root shell を取得する
  • 非特権ローカルアカウントさえあればよく、ネットワークアクセスやカーネルデバッグ機能、事前導入済みの他のプリミティブは不要

影響範囲

  • パッチ適用前のカーネルを使う 主要な Linux ディストリビューションの大半 が対象となる
  • デフォルト設定でカーネル暗号化 API の AF_ALG が事実上すべてのメインストリームディストリビューションで有効になっており、2017 年からパッチ時点までそのまま露出している
  • 直接検証したディストリビューションは Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL 14.3、SUSE 16
  • Debian、Arch、Fedora、Rocky、Alma、Oracle、組み込み系も、影響を受けるカーネルを使っていれば同様に動作する

優先的にパッチが必要な環境

  • マルチテナント Linux ホスト では複数ユーザーが同じカーネルを共有するため、任意のユーザーアカウントが直ちに root になり得る
  • Kubernetes / コンテナクラスター ではページキャッシュがホスト全体で共有されるため、1 つの pod がノードを掌握し、テナント境界を越えられる可能性がある
  • CI ランナーとビルドファーム では、一般ユーザー権限で実行された信頼できない PR コードが、ランナー上で root になり得る
  • ユーザーコード実行型 Cloud SaaS では、テナントがアップロードしたコンテナやスクリプトがホスト root につながる可能性がある
  • シングルテナントサーバーは内部 LPE の性格が強く、Web RCE や窃取された認証情報と結び付く可能性がある
  • 単一ユーザーのノート PC やワークステーションでは緊急度はやや低いが、ローカルコード実行がそのまま root 昇格につながる可能性がある

公開された PoC と使用方法

  • PoC は防御側がシステム検証やベンダーパッチ確認に活用できるよう公開されている
  • copy_fail_exp.py は Python 3.10+ の標準ライブラリ ossocketzlib のみを使用する
  • デフォルトの対象は /usr/bin/su で、argv[1] で別の setuid バイナリを渡せる
  • ページキャッシュ内の setuid バイナリを変更し、変更は再起動後に持続しないが、取得した root shell は実際に動作する
  • Issue tracker

緩和策

  • まず カーネルパッチ が必要であり、メインラインコミット a664bf3d603d を含むディストリビューションのカーネルへ更新する必要がある
  • このパッチは、2017 年に導入された algif_aead の in-place 最適化を巻き戻し、ページキャッシュページが writable destination scatterlist に入らないようにする
  • パッチ前は algif_aead モジュールの無効化 が推奨される
    • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
    • rmmod algif_aead 2>/dev/null || true
  • 信頼できないワークロードを実行するコンテナ、サンドボックス、CI では、パッチ有無に関係なく seccomp による AF_ALG ソケット生成の遮断 が必要

無効化時の影響

  • ほとんどのシステムでは 測定可能な影響はほぼない
  • dm-crypt / LUKSkTLSIPsec/XFRM、in-kernel TLS、OpenSSL/GnuTLS/NSS の標準ビルド、SSH、kernel keyring crypto は影響を受けない
    • これらはカーネル暗号化 API を直接利用しており、AF_ALG 経路を通らない
  • OpenSSL で afalg エンジンを明示的に有効にしている場合、一部の組み込み暗号オフロード経路、aead / skcipher / hash ソケットを直接 bind するアプリケーションは影響を受ける可能性がある
    • lsof | grep AF_ALG または ss -xa で確認できる
  • AF_ALG を無効化しても、もともとそれを呼び出していなかった対象は遅くならず、利用していた対象は一般的な userspace 暗号ライブラリへフォールバックする

一般的な Linux LPE と異なる点

  • 一般的な Linux LPE と異なり、レース条件がなく、ディストリビューションごとのオフセットも不要
  • 信頼性も 単発 100% とされ、狭いカーネルバージョン範囲ではなく 2017 年から 2026 年までの長期間をカバーする
  • Python 標準ライブラリだけを使う 732バイトのサイズ なので、コンパイル済みペイロードや追加依存関係がない
  • 書き込み経路が VFS を迂回 し、破損したページが dirty としてマークされないため、ディスクには何も書き込まれない
  • ページキャッシュはホスト全体で共有されるため、単純な LPE を超えて コンテナ脱出プリミティブ としても機能する

動作原理と検知特性

  • 非特権ローカルユーザーが Linux システムの 読み取り可能なファイルのページキャッシュ に制御可能な 4 バイトを書き込み、これを root 取得に利用できる
  • 標的はディスク上の実ファイルではなく メモリ内のページキャッシュ であり、/usr/bin/su のキャッシュコピーを変更すると、execve の観点ではバイナリ本体を変更したのと同等になる
  • ディスクに変化がないため inotify は反応せず、再起動やキャッシュ追い出し後には元のファイルが再ロードされる
  • sha256sum、AIDE、Tripwire のような一般的なハッシュツールは read() を通じてページキャッシュを読むため、キャッシュに破損が残っている間 は基準ハッシュと一致しない可能性がある
  • キャッシュが追い出されるか再起動されるとハッシュは再び元に戻り、ディスクフォレンジックイメージにも未改変のファイルしか残らない
  • IMA appraisal enforcing mode で every-read measurement が有効なら、破損したバイナリは実行前の execve 時点で検出できる

他の脆弱性との違い

  • Dirty Pipe と同系統であり、非特権 userspace からページキャッシュを破損させ、ディスク変更なしに setuid バイナリへ書き込んで root を得る点は共通している
  • メカニズムは異なり、Dirty Pipe は pipe buffer flags を悪用し、Copy Fail は chained scatterlist 境界を越える AEAD scratch write を悪用する
  • Dirty Pipe は特定のパッチが入ったカーネル 5.8 以降が必要だったが、Copy Fail は 2017 年から 2026 年までの範囲をカバーする
  • Dirty Cow と異なり、TOCTOU ベースの COW レースに勝つ必要がなく、何度も試行したりシステムを不安定化させたりしない

追加の詳細

  • /usr/bin/su は必須ではなく、ユーザーが読み取れる setuid-root バイナリ であれば passwdchshchfnmountsudopkexec も対象にできる
  • リモート脆弱性ではなく、まず 一般ユーザー権限でのローカルコード実行 が必要
  • Web RCE が非特権サービスアカウントに落ちる場合、SSH foothold、CI ランナー上の悪意ある PR などの経路と組み合わせることで root につながる可能性がある
  • パッチは algif_aead の in-place 最適化を巻き戻し、req->srcreq->dst を再び分離した scatterlist にする
  • ページキャッシュページは読み取り専用 source にのみ残り、暗号化が書き込める対象はユーザーバッファのみになる

公開スケジュールと後続資料

  • 2026-03-23 Linux カーネルセキュリティチームへ報告
  • 2026-03-24 初期確認が行われた
  • 2026-03-25 パッチが提案されレビューされた
  • 2026-04-01 メインラインへパッチがコミットされた
  • 2026-04-22 CVE-2026-31431 が割り当てられた
  • 2026-04-29 https://copy.fail/ で公開
  • Xint blog 技術分析
    • root cause、scatterlist 図、2011→2015→2017 の沿革、エクスプロイトのウォークスルーを含む
    • Kubernetes コンテナ脱出を扱う Part 2 は後日公開予定

Xint Code 関連情報

  • AI-assisted な手法で発見され、出発点は splice() がページキャッシュページを crypto subsystem に渡す点と、scatterlist のページ出所があまり探索されていないバグクラスかもしれないという人間の研究だった
  • その後 Xint Code が Linux crypto/ subsystem 全体の監査を約 1 時間規模に拡張し、その結果のうち 最も深刻な項目 が Copy Fail だった
  • Xint Code
    • Xint blog write-up
    • 同じスキャンで他の高リスクバグも発見されており、これらはまだ coordinated disclosure 中

まだコメントはありません。

まだコメントはありません。