Copy Fail / Dirty Frag Mitigation for Yandex Managed Kubernetes

Yandex Managed Kubernetes クラスタの全 worker ノードにおいて、Linux kernel の脆弱性 CVE-2026-31431、CVE-2026-43284、CVE-2026-43500 に対する緩和策を自動的に適用します。

脆弱性の説明

CVE ID: CVE-2026-43284、CVE-2026-43500

CVE へのリンク: https://nvd.nist.gov/vuln/detail/CVE-2026-43284

元のレポート:

Dirty Frag (PoC および write-up): https://github.com/V4bel/dirtyfrag
Copy Fail 2: Electric Boogaloo (PoC xfrm-ESP): https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo
oss-security メーリングリスト: https://www.openwall.com/lists/oss-security/2026/05/07/8

概要:

Dirty Frag は Linux カーネルにおける論理的脆弱性のクラスであり、非特権のローカルユーザーがスーパーユーザー (root) 権限を取得できるようにします。この悪用は、xfrm-ESP と RxRPC サブシステムにおける 2 つの独立した page-cache write プリミティブを組み合わせたもので、それぞれが単独で権限昇格に十分です。

Copy Fail 2: Electric Boogaloo は、xfrm-ESP プリミティブ (CVE-2026-43284) を悪用する独立した PoC です。脆弱性のクラスとしては元の Copy Fail (CVE-2026-31431) と類似しているため、この DaemonSet は元の AF_ALG シナリオと新しい Dirty Frag の亜種の両方に対する緩和策を保持します。

攻撃:

リモートアクセスは不要 - 非特権のローカルアカウントのみで可能
race condition のない決定論的な論理バグ - 最初の試行で成功
悪用に失敗しても kernel panic を引き起こさない
page cache はノード全体で共有されるため、コンテナからホストへのエスケーププリミティブとして使用可能

両方の亜種の根本原因は同じです: splice() / MSG_SPLICE_PAGES を使用すると、カーネルは page cache のページをソケットバッファ (skb) のフラグメントに直接配置します。xfrm-ESP と RxRPC サブシステムは、これらのフラグメントがプライベートであるかどうかを確認せずに、その場で復号化を実行します。その結果、攻撃者は読み取り可能な任意のファイルの page cache への制御された書き込みを取得できます。

影響を受ける技術:

Linux カーネル、net/ipv4/esp4.c / net/ipv6/esp6.c サブシステム (xfrm-ESP)
Linux カーネル、net/rxrpc/rxkad.c サブシステム (RxRPC / RxKAD)
UDP ソケット (ESP-in-UDP) および AF_RXRPC と組み合わせた splice() / vmsplice() システムコール
元の Copy Fail (CVE-2026-31431) の緩和策は、AF_ALG (algif_aead) のブロックを通じて個別に保持されます

この脆弱性は、Dirty Frag の一部として AF_ALG (algif_aead) に直接影響を与えるものではありません - これは別の脆弱性 Copy Fail (CVE-2026-31431) です。また、dm-crypt / LUKS、kTLS、in-kernel TLS、および UDP カプセル化なしの tunnel モードの IPsec にも直接影響しません。

CVSS v.3.1 による攻撃ベクトルと危険度:

基本評価: 公開時点では割り当てられていません。

性質上、この脆弱性は Copy Fail (CVE-2026-31431、7.8 HIGH、CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) と類似しています - race condition のないローカル権限昇格です。

このフィックスの機能

DaemonSet はクラスタの各 worker ノードで自動的に以下を実行します:

AF_ALG の可用性を確認 - 元の Copy Fail シナリオのクイックテストを実行
脆弱なモジュールをブロック - algif_aead、esp4、esp6、rxrpc のルールを含む /etc/modprobe.d/blacklist-lpe.conf を作成
モジュールをアンロード - ロードされている場合、algif_aead、esp4、esp6、rxrpc に対して rmmod を実行
page cache をリセットし、設定を検証 - キャッシュをクリアし、設定ファイルの存在を確認
状態を監視 - 毎時間設定の存在を確認し、必要に応じてモジュールを再アンロード

クイックスタート

1. DaemonSet をダウンロード

wget https://raw.githubusercontent.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation/main/copy-fail-mitigation-daemonset.yaml

またはリポジトリをクローン:

git clone https://github.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation.git
cd yc-mk8s-copy-fail-mitigation

2. フィックスを適用

kubectl apply -f copy-fail-mitigation-daemonset.yaml

3. 適用ステータスを確認

# DaemonSet のステータスを確認
kubectl get daemonset -n kube-system cve-2026-31431-fix

# フィックスが適用されたノード数を確認
kubectl get pods -n kube-system -l app=cve-2026-31431-fix -o wide

4. フィックス適用のログを表示

# initContainer のログ (フィックスの適用)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c apply-fix

# メインコンテナのログ (監視)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c monitor

適用成功の例

=========================================
Copy Fail / Dirty Frag mitigation for Yandex Managed K8s
Node: demo-ru-central1-a-1
Date: Thu May 08 14:00:00 UTC 2026
=========================================

Step 1: Checking vulnerability before fix...
❌ System is VULNERABLE - AF_ALG AEAD interface is accessible

Step 2: Creating modprobe configuration...
✓ Created /etc/modprobe.d/blacklist-lpe.conf

Step 3: Unloading vulnerable modules...
  ✓ algif_aead unloaded
  ✓ esp4 not loaded
  ✓ esp6 not loaded
  ✓ rxrpc not loaded

Step 3.5: Dropping system caches...
✓ System caches cleared

Step 4: Verifying the fix...
✓ Configuration file exists:
install algif_aead /bin/false
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Step 5: Testing if vulnerability is fixed...
✓ AF_ALG AEAD interface is properly blocked

=========================================
✓ Mitigation applied successfully
=========================================

手動での脆弱性確認

ノード上の脆弱性を手動で確認できます。SSH でノードに接続し、以下を実行してください:

# AF_ALG 経由の元の Copy Fail シナリオの可用性を確認
python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("AF_ALG AEAD available - VULNERABLE")'

# "AF_ALG AEAD available - VULNERABLE" と出力された場合 - システムは脆弱
# エラーが出力された場合 - システムは保護されています

設定を確認:

# ブロック設定の存在を確認
cat /etc/modprobe.d/blacklist-lpe.conf

# 期待される出力:
# install algif_aead /bin/false
# install esp4 /bin/false
# install esp6 /bin/false
# install rxrpc /bin/false

脆弱なモジュールがロードされていないことを確認:

lsmod | egrep 'algif_aead|esp4|esp6|rxrpc'

フィックスの削除

DaemonSet を削除する必要がある場合:

kubectl delete -f copy-fail-mitigation-daemonset.yaml

重要: DaemonSet を削除しても、ノードから設定ファイルは削除されません。/etc/modprobe.d/blacklist-lpe.conf ファイルはその場に残り、システムを保護し続けます。

ノードからフィックスを完全に削除するには、各ノードに SSH で接続し、ファイルを手動で削除する必要があります:

rm /etc/modprobe.d/blacklist-lpe.conf

技術的詳細

使用される権限:

hostPID: true - nsenter 経由でホストのプロセスにアクセスするため
privileged: true - /etc への書き込みとカーネルモジュールのアンロードのため
Volume mount / - ホストのファイルシステムへのアクセスのため

イメージ: ubuntu:22.04

リソース:

Init container: 10m CPU / 64Mi RAM (requests)、200m CPU / 128Mi RAM (limits)
Monitor container: 5m CPU / 32Mi RAM (requests)、50m CPU / 64Mi RAM (limits)

Namespace: kube-system

互換性

✓ Yandex Managed Kubernetes
✓ Ubuntu 20.04
✓ Ubuntu 22.04
✓ Kubernetes 1.20+

ライセンス

Apache License 2.0

詳細は LICENSE を参照してください。

サポート

問題が発生した場合は、リポジトリに issue を作成してください。

yc-mk8s-copy-fail-mitigation

人気