Copy Fail / Dirty Frag Mitigation für Yandex Managed Kubernetes

Automatische Anwendung der Mitigation für die Schwachstellen CVE-2026-31431, CVE-2026-43284 und CVE-2026-43500 im Linux-Kernel auf allen Worker-Nodes des Yandex Managed Kubernetes Clusters.

Beschreibung der Schwachstelle

CVE-ID: CVE-2026-43284, CVE-2026-43500

CVE-Link: https://nvd.nist.gov/vuln/detail/CVE-2026-43284

Ursprünglicher Bericht:

Dirty Frag (PoC und 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-Mailingliste: https://www.openwall.com/lists/oss-security/2026/05/07/8

Kurzbeschreibung:

Dirty Frag ist eine Klasse logischer Schwachstellen im Linux-Kernel, die es einem nicht privilegierten lokalen Benutzer ermöglicht, Superuser-Rechte (root) zu erlangen. Die Ausnutzung kombiniert zwei unabhängige Page-Cache-Write-Primitive in den Subsystemen xfrm-ESP und RxRPC, von denen jedes für sich allein zur Rechteausweitung ausreicht.

Copy Fail 2: Electric Boogaloo ist ein unabhängiger PoC, der das xfrm-ESP-Primitiv (CVE-2026-43284) ausnutzt. Von der Schwachstellenklasse her ist er analog zum ursprünglichen Copy Fail (CVE-2026-31431), daher bewahrt dieses DaemonSet die Mitigation sowohl für das ursprüngliche AF_ALG-Szenario als auch für die neuen Dirty Frag-Varianten.

Angriff:

erfordert keinen Remote-Zugriff - nur ein nicht privilegiertes lokales Konto
ist ein deterministischer logischer Bug ohne Race Condition - erfolgreich beim ersten Versuch
führt bei fehlgeschlagener Ausnutzung nicht zu einem kernel panic
kann als Primitiv zur Container-Escape auf den Host verwendet werden, da der page cache für den gesamten Node gemeinsam ist

Die Grundursache beider Varianten ist dieselbe: Bei Verwendung von splice() / MSG_SPLICE_PAGES legt der Kernel page cache-Seiten direkt in die Fragmente der Socket-Puffer (skb). Die Subsysteme xfrm-ESP und RxRPC führen eine In-place-Entschlüsselung über solchen Fragmenten durch, ohne zu prüfen, ob diese privat sind. Dadurch erhält der Angreifer einen kontrollierten Schreibzugriff auf den page cache jeder lesbaren Datei.

Betroffene Technologien:

Linux-Kernel, Subsystem net/ipv4/esp4.c / net/ipv6/esp6.c (xfrm-ESP)
Linux-Kernel, Subsystem net/rxrpc/rxkad.c (RxRPC / RxKAD)
Systemaufrufe splice() / vmsplice() in Verbindung mit UDP-Sockets (ESP-in-UDP) und AF_RXRPC
Die Mitigation des ursprünglichen Copy Fail (CVE-2026-31431) bleibt separat über die Blockierung von AF_ALG (algif_aead) erhalten

Die Schwachstelle betrifft AF_ALG (algif_aead) nicht direkt als Teil von Dirty Frag - dies ist eine separate Schwachstelle Copy Fail (CVE-2026-31431). Ebenfalls nicht direkt betroffen sind dm-crypt / LUKS, kTLS, In-Kernel-TLS und IPsec im Tunnel-Modus ohne UDP-Kapselung.

Angriffsvektor und Gefährdungsgrad gemäß CVSS v.3.1:

Basisbewertung: Zum Zeitpunkt der Veröffentlichung nicht zugewiesen.

Von der Natur her ist die Schwachstelle analog zu 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) - eine lokale Rechteausweitung ohne Race Condition.

Was dieser Fix bewirkt

Das DaemonSet führt automatisch auf jeder Worker-Node des Clusters folgende Schritte aus:

Prüft die Verfügbarkeit von AF_ALG - führt einen schnellen Test für das ursprüngliche Copy Fail-Szenario durch
Blockiert verwundbare Module - erstellt /etc/modprobe.d/blacklist-lpe.conf mit Regeln für algif_aead, esp4, esp6 und rxrpc
Entlädt Module - führt rmmod für algif_aead, esp4, esp6 und rxrpc aus, falls diese geladen sind
Setzt den page cache zurück und verifiziert die Konfiguration - leert die Caches und prüft das Vorhandensein der Konfigurationsdatei

Schnellstart

1. DaemonSet herunterladen

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

Oder das Repository klonen:

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

2. Fix anwenden

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

3. Status der Anwendung prüfen

# DaemonSet-Status prüfen
kubectl get daemonset -n kube-system cve-2026-31431-fix

# Anzeigen, auf wie vielen Nodes der Fix angewendet wurde
kubectl get pods -n kube-system -l app=cve-2026-31431-fix -o wide

4. Logs der Fix-Anwendung anzeigen

# Logs des initContainer (Anwendung des Fixes)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c apply-fix

# Logs des Hauptcontainers (Überwachung)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c monitor

Beispiel einer erfolgreichen Anwendung

=========================================
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
=========================================

Manuelle Prüfung der Schwachstelle

Sie können das Vorhandensein der Schwachstelle auf einem Node manuell prüfen. Verbinden Sie sich per SSH mit dem Node und führen Sie Folgendes aus:

# Verfügbarkeit des ursprünglichen Copy Fail-Szenarios über AF_ALG prüfen
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")'

# Wenn "AF_ALG AEAD available - VULNERABLE" ausgegeben wird - ist das System verwundbar
# Wenn ein Fehler ausgegeben wird - ist das System geschützt

Konfiguration prüfen:

# Vorhandensein der Blockierungskonfiguration prüfen
cat /etc/modprobe.d/blacklist-lpe.conf

# Erwartete Ausgabe:
# install algif_aead /bin/false
# install esp4 /bin/false
# install esp6 /bin/false
# install rxrpc /bin/false

Prüfen, dass die verwundbaren Module nicht geladen sind:

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

Entfernen des Fixes

Wenn das DaemonSet entfernt werden muss:

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

Wichtig: Das Entfernen des DaemonSets entfernt nicht die Konfigurationsdateien von den Nodes. Die Datei /etc/modprobe.d/blacklist-lpe.conf bleibt bestehen und schützt das System weiterhin.

Für die vollständige Entfernung des Fixes von den Nodes müssen Sie sich per SSH mit jeder Node verbinden und die Datei manuell löschen:

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

Technische Details

Verwendete Berechtigungen:

hostPID: true - für den Zugriff auf Host-Prozesse über nsenter
privileged: true - zum Schreiben in /etc und zum Entladen von Kernel-Modulen
Volume-Mount / - für den Zugriff auf das Host-Dateisystem

Image: ubuntu:22.04

Ressourcen:

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

Kompatibilität

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

Lizenz

Apache License 2.0

Siehe LICENSE für Details.

Support

Bei Problemen erstellen Sie bitte ein Issue im Repository.

yc-mk8s-copy-fail-mitigation

Beliebteste