runCの脆弱性でDockerからホストへコンテナ脱出の恐れ - SecureShield セキュリティニュースまとめ

Source:https://www.bleepingcomputer.com/news/security/dangerous-runc-flaws-could-allow-hackers-to-escape-docker-containers/

🛡 概要

DockerやKubernetesで広く使われるコンテナランタイム「runC」に、コンテナ隔離を迂回してホストへ到達し得る重大な欠陥が3件報告されています（CVE-2025-31133、CVE-2025-52565、CVE-2025-52881）。いずれもマウント処理や/procへの書き込みを悪用して、攻撃者がホスト上でroot権限の書き込みを得られる可能性があります。CVE-2025-31133とCVE-2025-52881は全バージョンに影響、CVE-2025-52565はrunC 1.0.0-rc3以降が対象です。修正版は1.2.8、1.3.3、1.4.0-rc.3以降。現時点で悪用の公表事例は確認されていません。CVSSは公表待ちです。

🔍 技術詳細

runCはコンテナ起動時に、名前空間やマウント、cgroupsなどの低レベル初期化を担当します。この初期化フローのうち、以下の処理が悪用され得ます。

CVE-2025-31133：runCは機微なホストファイルを「/dev/null のbind mount」でマスクします。コンテナ初期化の瞬間に、コンテナ側の/dev/nullを攻撃者がシンボリックリンクへ置換できると、runCが想定外のパスをbind mount（読書き可）してしまい、/proc下の危険なエントリへの書き込みを許します。結果としてコンテナ脱出の足掛かりになります。
CVE-2025-52565：/dev/consoleのbind mountに関し、競合状態やシンボリックリンク操作によって、保護適用前に想定外のターゲットをコンテナへマウントさせられる恐れがあります。これにより、重要なprocfsエントリへの書き込み経路が再び開かれ、脱出につながります。影響はrunC 1.0.0-rc3以降。
CVE-2025-52881：runCによる/procへの正規の書き込みが、シンボリックリンク操作により攻撃者制御パスへリダイレクトされるケースがあります。バリアントによってはLSM（SELinux/AppArmor）のrelabel保護を回避でき、/proc/sysrq-trigger のような危険ファイルへの任意書き込みに転化します。

3件とも本質的には、コンテナ初期化中の「bind mountターゲット解決」と「/proc書き込み」の間隙を、シンボリックリンクやレースコンディションで突くクラスの不備です。研究者らは、悪用には「カスタムマウント構成でコンテナを起動できる権限（不正なイメージ/Dockerfile含む）」が要件になると指摘しています。Kubernetes/コンテナd/CRI-O/Docker Engineはいずれも内部でrunCを呼び出すため、基盤側でrunCを更新しない限り影響は残存します。公式修正はrunC 1.2.8、1.3.3、1.4.0-rc.3以降で提供済みです。緩和策として「user namespaces（ホストrootをマッピングしない）」「rootlessコンテナ」の有効化が推奨されます。UNIX DACにより/proc等への書き込みが制限され、攻撃成立の主要部分を阻止できます。

⚠ 影響

ノードのホスト権限奪取：/proc/sysrq-trigger等への書き込みを足掛かりに、ホスト上での任意コード実行・サービス妨害が起き得ます。
クラスター横展開：ノード支配後はKubernetes機密（kubelet認証情報、CNI設定等）へ到達し、横展開・権限昇格の可能性。
サプライチェーン悪用：不正イメージ/不審なDockerfile経由での初期侵入、CI/CDランナーからの脱出。

なお、現時点で広範な悪用の公表はありませんが、マルチテナントや共有ノード環境ではリスクが高くなります。

🛠 対策

至急パッチ：ランタイム/ディストリのrunCが1.2.8/1.3.3/1.4.0-rc.3以降であることを確認。Docker Engine、containerd、CRI-Oパッケージも連動更新。
User namespaces：全コンテナで有効化（ホストroot非マッピング）。KubernetesはRuntimeClassやデーモン設定で適用。
Rootlessコンテナ：可能なワークロードで採用し、被害半径を縮小。
Pod/コンテナの権限最小化：allowPrivilegeEscalation: false、capabilities: drop ALL、readOnlyRootFilesystem: true、privileged/hostPath/hostPID/hostIPC禁止（Pod Security: restricted）。
Admission/Policy：カスタムマウント（特に/dev、/proc関連）を含むPod/Compose設定を拒否・要審査。OPA Gatekeeper/Kyvernoでガードレール実装。
イメージ健全性：/dev/null・/dev/consoleがキャラクタデバイスであることをCIで検証（シンボリックリンク混入を検出）。SBOMと署名検証を徹底。
LSM/カーネル防御：SELinux/AppArmor強制、seccomp有効化、kernel.sysrq=0の確認、procマウントの制限（hidepid等、可能な範囲で）。

📌 SOC視点

シスコール/EDR：mount(2)、openat(2)、linkat(2)、write(2)の連続で/proc配下（特に/proc/sysrq-trigger、/proc/sys/）へ書き込みを試みるパターンを検知。seccomp監視、auditdでのルール追加例：-w /proc/sysrq-trigger -p wa -k sysrq、-a always,exit -S mount -F exe=/usr/bin/runc -k runc_mounts（パスは環境に応じ調整）。
ランタイムイベント：containerd/cri-o/dockerのイベントで、コンテナ作成時に「/dev/null」「/dev/console」向けの非標準マウントやprocfsのrwマウントを検知・隔離。
ファイル整合性：コンテナ内/dev直下における/dev/null・/dev/consoleがキャラクタデバイスでない場合のアラート。イメージスキャンでシンボリックリンク混入を検出。
K8s監査：AdmissionログでhostPath、特権、mountPropagation等の危険設定要求を可視化。攻撃失敗痕跡としてシンボリックリンク作成の失敗や許可拒否イベントも相関分析。

📈 MITRE ATT&CK

TA0004 Privilege Escalation / TA0005 Defense Evasion：T1611 Escape to Host (Containers)。runCのマウント処理や/proc書き込みを悪用してコンテナ境界を突破し、ホスト権限を得る挙動に合致。
TA0004 Privilege Escalation：T1068 Exploitation for Privilege Escalation。既知のランタイム脆弱性を突いて権限拡大を達成。
TA0002 Execution / TA0003 Persistence（フォローオン）：脱出後はT1053.003 Scheduled Task/CronやT1543.002/003 Create or Modify System Process（systemd等）で永続化が想定される。

根拠：いずれのCVEもコンテナ→ホスト境界の回避（マウント/プロック書き込み）を通じたエスカレーションであり、T1611/T1068に該当します。

🏢 組織規模別助言

小規模（〜50名）：まずは使用中のDocker/コンテナd/CRI-OのrunCバージョンを棚卸しし、ホスト全台に更新を即時適用。特権コンテナやhostPathを恒久禁止し、rootlessへの移行を段階実施。
中規模（50〜500名）：ステージングで検証後に段階的ロールアウト。Kyverno/Gatekeeperでrestrictedポリシーを強制、CIに/dev健全性チェックを追加。SOCでauditd・Falco等のルールを即日展開。
大規模（500名〜）：フリート管理（Fleet/Ansible）でノード横断パッチ、カナリア展開と自動ロールバック。クラスタ多層防御（PSA: restricted、RuntimeClassでuserns/rootless強制）、脆弱性SLAと例外管理を運用に組込み。