CVE-2026-31431 (Copy Fail) - 私たちはどう緩和したか

先週、深刻な Linux カーネルのローカル権限昇格脆弱性 CVE-2026-31431、通称 "Copy Fail" が公開されました。これは最新の Linux ディストリビューションに含まれる幅広いカーネルバージョンに影響し、公開後すぐに実証コードも出回りました。

何が起きたのか、Appbox にとって何を意味するのか、そして私たちが何を行ったのかを率直に説明します。短く言えば、私たちのコンテナ構成により、user namespace remapping で動作しているアプリは、修正済みカーネルの展開前から、これが host root につながることは防がれていました。さらに昨日（May 4, 2026）、全サーバーを修正済みカーネルへ更新する緊急メンテナンスも実施したため、このバグは現在、当社 fleet から完全に除去されています。

"Copy Fail" とは？

CVE-2026-31431 は、カーネルの AF_ALG 暗号 API にある欠陥です。特定の cipher（authencesn(hmac(sha256),cbc(aes))）へ bind し、カーネルがページを scratch buffer へ splice する方法を悪用することで、権限のないローカルユーザーが、本来変更権限を持たないファイルの page cache へ直接 任意の4バイト単位を書き込めます。対象には /usr/bin/su のような SUID バイナリも含まれます。

su の page cache コピーが小さな悪意ある ELF で上書きされると、次回実行時に攻撃者のコードが UID 0 として動作します。ホストにとっては致命的です。

詳細な技術内容（shellcode の逆アセンブル、syscall trace など）については、Andrea Veri 氏の解説が非常に優れています: CVE-2026-31431: Copy Fail vs. rootless containers。同氏は eBPF と uid_map の証明を使い、次に説明する点、つまり user namespaces がこの exploit を無力化することも実証しています。

Appbox アプリがすでに緩和されていた理由

この exploit は、setuid(0) が実際に host root を与えることに依存しています。user namespaces が有効なコンテナでは、そうはなりません。

User namespaces は、コンテナ内の UID 空間を、ホスト上の別の（権限のない）UID 範囲へマッピングします。そのため、コンテナ内で exploit が成功し setuid(0) が成功を返しても、その結果得られる "root" shell は、ホスト上では 通常の非特権ユーザー にマッピングされます。本当に root になるわけではありません。shellcode は動き、プロンプトは # に変わりますが、ホスト上では次のような状態です。

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

それだけです。ホストファイルへのアクセスも、/etc/shadow も、host root もありません。コンテナの namespace 境界が、これを host-root escape に発展させることを止めます。

プラットフォームレベルでは、各 Appbox が user namespace remapping を有効にした独自の Docker daemon を起動します。擬似コードでは次のような形です。

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

このマッピングは、ホスト上の専用 subordinate UID/GID 範囲によって裏付けられています。

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

さらに、アプリが特別な扱いを必要とする場合は、アプリ定義で UsernsMode を明示的に上書きできます。

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

つまり正確には、user namespace remapping はプラットフォームの既定動作の一部であり、アプリごとの例外は明示的に扱われます。追加 capability が必要な機能を提供するため、異なる設定が必要なアプリが少数ありますが、それらは個別に扱われます。

言い換えると、通常の remapped 設定で動作するアプリでは、Copy Fail がコンテナ侵害を host root に発展させることはできませんでした。

それでも修正したかったこと

User namespaces はホスト escape を防ぎますが、コンテナ内のバグ自体を消すわけではありません。攻撃者はアプリ境界内で "container root" へ昇格できる可能性があり、封じ込められているとはいえ望ましい状態ではありません。カーネル自体は脆弱であり、私たちはそれをなくしたいと考えました。

このバグを把握した時点で、すぐに影響範囲の評価を開始しました。通常のアプリ構成では user namespace remapping によりホスト escape 側はすでに防げていましたが、それでも基礎となるカーネルバグは可能な限り早く取り除きたいと考えました。

昨日行ったこと

日曜夜、fleet 全体のカーネルアップグレードを展開できる最短の枠として、Monday, May 4, 2026 に緊急メンテナンスを予定しました。

メンテナンス枠の間に:

• すべてのホストを、"Copy Fail" 修正を含む公式 Debian カーネルパッケージでアップグレードしました。
• 目的は単純でした。既存の namespace 分離だけに頼るのではなく、脆弱なカーネル経路そのものを取り除くことです。

メンテナンスは完了しています。すべての Appbox ホストは現在、修正済みカーネルで稼働しています。

お客様への影響

• お客様側で必要な作業はありませんでした。アプリは動作を継続し、メンテナンス枠中の短時間の影響だけがお客様に見える可能性のある影響でした。
• 昨日のパッチ適用前でも、user namespace remapping により、このバグが通常のアプリ侵害を host root に発展させることはできませんでした。まさに、この分離モデルが想定しているシナリオです。
• 今後も方針は変わりません。user namespaces は既定で有効のまま維持し、ごく少数の例外には追加のセキュリティレビューを行います。

より大きな視点

これは、見出しだけ見ると（「ローカル権限昇格」「公開 exploit」「すべての最新カーネルが影響」）壊滅的に見える CVE の一つです。多くの共有テナント環境にとっては実際に壊滅的でした。Appbox でそうならなかった理由は、互換性面で多少のコストを払うことがあっても、何年も前に行ったアーキテクチャ上の判断と同じです。私たちは、アプリを最小権限の原則をコンテナレイヤーに最初から組み込んだ形で実行しており、後から付け足しているわけではありません。

Defense in depth は本当に機能します。カーネル層のバグ？ namespace 層が受け止めました。namespace 層のバグ？ capability drops と seccomp が多くを受け止めます。どれか1つの層が完璧だとは考えていません。ただ、必ず次の層があるようにしています。

この件や、お使いの特定アプリがどのように構成されているかについて質問があれば、お問い合わせください。

ご質問がありますか？support@appbox.co へ連絡するか、billing.appbox.co でチケットを開いてください。