SEKurity GmbH Logo
CVE-Forschung

InSEKurity der Woche (KW18/2026): Linux Kernel "Copy Fail" Privilege Escalation (CVE-2026-31431)

Ein neun Jahre alter Logikfehler im Linux-Kernel-Modul algif_aead erlaubt jedem lokalen Benutzer einen kontrollierten 4-Byte-Schreibzugriff in den Page Cache jeder lesbaren Datei -- Root, Container-Escape, kein Race Condition, oeffentlicher PoC

SEKurity Team

Offensive Security Experten

19 Min. Lesezeit
Teilen:

Diese Woche in unserer InSEKurity der Woche-Serie: ein neun Jahre alter Logikfehler im Linux-Kernel-Modul algif_aead, der jedem lokalen, unprivilegierten Benutzer einen kontrollierten 4-Byte-Schreibzugriff in den Page Cache des Kernels für jede lesbare Datei ermöglicht — und von dort aus den Sprung zu Root, indem er die In-Memory-Kopie von /usr/bin/su oder einem anderen privilegierten Binary manipuliert. Die Schwachstelle — CVE-2026-31431, gebrandmarkt als „Copy Fail” — erreicht jede gängige Distribution mit einem seit 2017 gebauten Kernel, lässt sich deterministisch ohne Race Condition ausnutzen und durchbricht Container-Grenzen, weil der Page Cache zwischen Host und allen Containern auf demselben Knoten geteilt wird. Ein öffentlicher PoC liegt bereits auf GitHub, der Exploit passt in rund 732 Bytes Python, und CISA hat die CVE am 01.05.2026 in den Known Exploited Vulnerabilities Catalog aufgenommen mit einer Patch-Frist für US-Behörden zum 15.05.2026. Wenn Sie Linux-Flotten, Kubernetes-Cluster, mehrmandantenfähige Cloud-Workloads oder CI/CD mit nicht-vertrauenswürdigem Code betreiben, ist dies die Patch-now-CVE des Monats.

Zusammenfassung

  • CVE-ID: CVE-2026-31431 (Alias „Copy Fail” / „CopyFail”)
  • CVSS-3.1-Score: 7.8 (Hoch)
  • CVSS-Vektor: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  • CWE: CWE-669 (Incorrect Resource Transfer Between Spheres)
  • Betroffene Software: Linux-Kernel algif_aead (AF_ALG-AEAD-Socket-Interface) — jeder Mainline-Kernel von 4.14 bis zu den unten gelisteten gepatchten LTS-Releases; ausgeliefert in Ubuntu (Bionic / Focal / Jammy / Noble / Questing), Debian (sid gepatcht, stable / Bookworm verwundbar), RHEL 8 / 9 / 10, Amazon Linux 2023, SUSE 16, Fedora, Rocky Linux 9.7, Arch Linux und den meisten Container-Base-Images
  • Angriffsvektor: Lokal (unprivilegierter Benutzer auf dem Zielsystem; aus einem Container heraus erreichbar)
  • Authentifizierung erforderlich: Ja — niedrig privilegiertes lokales Konto
  • Benutzerinteraktion: Keine
  • Auswirkung: Kontrollierter 4-Byte-Schreibzugriff in den Page Cache jeder lesbaren Datei -> Manipulation des In-Memory-Abbilds privilegierter Binaries -> Root auf dem Host -> Container-Escape auf gemeinsamen Kerneln
  • Patch-Status: Verfügbar — Mainline-Fix crypto: algif_aead - Revert to operating out-of-place (Kernel-Commit a664bf3d603d, 01.04.2026); Per-LTS-Releases siehe unten
  • Veröffentlicht: NVD 22.04.2026; koordinierte Disclosure 29.04.2026
  • Gemeldet von: Taeyang Lee von Theori (entdeckt mit dem KI-gestützten Code-Analyse-Tool Xint Code)
  • Exploitation-Status: Öffentlicher PoC verfügbar (~732-Byte-Python-Skript auf GitHub); deterministisch; keine Race Condition; am 01.05.2026 in CISA KEV gelistet mit Frist für US-Behörden 15.05.2026

Was ist algif_aead / AF_ALG?

AF_ALG ist die Userspace-Crypto-API des Linux-Kernels: eine Socket-Familie, die einem Prozess erlaubt, den Kernel über einen Socket symmetrische, Hash-, AEAD- oder RNG-Operationen ausführen zu lassen. Der User-Land-Code spricht mit einem Kernel-Modul — algif_skcipher für symmetrische Cipher, algif_hash für Hashes, algif_aead für Authenticated Encryption with Associated Data (AEAD). Der Hauptvorteil ist Zugriff auf hardware-beschleunigte Krypto (AES-NI, ARM CryptoExtensions, dedizierte Beschleuniger), ohne sich an eine spezifische Userspace-Bibliothek zu binden.

algif_aead verdrahtet AEAD-Konstruktionen wie AES-GCM, ChaCha20-Poly1305 und das Encrypt-then-MAC-Template authencesn mit dem AF_ALG-Socket-Plumbing. Produktive Aufrufer sind unter anderem cryptsetup / LUKS für die Disk-Verschlüsselungs-Einrichtung, in einigen Distros firefox-esr und ein langer Schwanz an Diensten, die kernelseitige Krypto OpenSSL vorziehen. Das Modul wird autoloaded, sobald irgendein Prozess einen AF_ALG-Socket vom Typ aead öffnet — das heißt, ein unprivilegierter Prozess auf einem standardmäßig konfigurierten Linux-Host kann den verwundbaren Code-Pfad bei Bedarf aktivieren.

Typische Anwendungsfälle

  • LUKS / dm-crypt-Setup über cryptsetup — AEAD-Modi für authentifizierte Disk-Verschlüsselung.
  • Kernel-TLS (kTLS)-Offload-Pfade, die auf AF_ALG zurückfallen, wenn keine Inline-Crypto-Offload verfügbar ist.
  • Container-Images, die hardware-beschleunigtes AEAD nutzen — das Modul ist auf praktisch jeder Distro standardmäßig aktiv.
  • Kubernetes-Workloads mit Krypto-Bibliotheken, die opportunistisch AF_ALG bevorzugen.
  • Embedded- und IoT-Linux mit ausreichend neuen Kerneln (4.14+) — Router, NVRs, Industrial Gateways.
  • Cloud-Linux-VMs auf Azure, AWS, GCP — einschließlich der Marketplace-Images, die Microsoft im eigenen Writeup hervorhebt.

Da algif_aead durch einen unprivilegierten Socket-Aufruf geladen wird, benötigt der Angreifer kein Root, um den Bug zu erreichen — nur Code-Ausführung auf dem System. Das macht Container, mehrmandantenfähige VMs, geteilte Entwicklungsmaschinen und CI/CD-Runner zu Hochrisikozielen.

Technische Analyse

Schwachstellenbeschreibung

CVE-2026-31431 ist ein Incorrect Resource Transfer Between Spheres (CWE-669) in algif_aead. Die Commit-Message des Linux-Kernel-Maintainers zur Behebung beschreibt den Fix knapp: „crypto: algif_aead - Revert to operating out-of-place”. Der Bug ist die Umkehrung davon: eine In-Place-Optimierung, die 2017 in algif_aead.c hinzugefügt wurde, lässt den Kernel den Quell-Speicher als Zielspeicher einer AEAD-Operation wiederverwenden, unter der Annahme, dass die Scatter-Gather-Listen auf beiden Seiten der Operation auf dieselben Pages zeigen.

Diese Annahme bricht zusammen, wenn die Quell-Pages und die Ziel-Pages aus unterschiedlichen Kernel-„Sphären” stammen — konkret, wenn der Angreifer mit splice(2) den Page Cache einer Datei, die er nur lesen kann, als Eingabe in die AEAD-Operation einspeist, während das Ziel auf vom Angreifer kontrollierten Speicher zeigt. Der Kernel schreibt die AEAD-Ausgabe zurück in die Quellseite des splice, und diese Quellseite ist der Page Cache der Zieldatei. Das Ergebnis ist ein deterministischer, kontrollierter 4-Byte-Schreibzugriff in die In-Memory-Kopie jeder Datei, die der Angreifer mit open(O_RDONLY) öffnen kann — darunter SUID-Binaries, der Dynamic Linker, Kernel-Module auf der Disk, Container-Layer-Dateien und so weiter.

Die On-Disk-Datei wird nie verändert. Die Änderung lebt vollständig im Page Cache, sodass File-Integrity-Tools (AIDE, Tripwire, dm-verity, auditd-File-Watches, Paketmanager-Checksummen) nichts sehen. Sobald der nächste Prozess das Ziel-Binary ausführt, mappt der Kernel die korrumpierte Page in den Adressraum des neuen Prozesses und führt sie aus.

Root-Cause-Analyse

  1. Drei-Stufen-Historie (2011 / 2015 / 2017): der Bug ist die Wechselwirkung dreier unabhängiger Kernel-Änderungen — das authencesn-AEAD-Template (2011), AF_ALG-AEAD-Socket-Support (2015) und die In-Place-Optimierung in algif_aead.c (2017). Keine der drei Änderungen ist isoliert falsch; kombiniert verletzen sie die implizite Grenze zwischen Quell- und Zielsphäre der AEAD-Operation.
  2. Scatter-Gather-Aliasing (CWE-669): die In-Place-Optimierung nimmt an, dass die Quell- und Ziel-Scatter-Gather-Listen denselben Speicher beschreiben. Wenn eine splice()-Grenze Quell-Pages erzeugt, die durch den Page Cache einer Read-only-Datei unterlegt sind, wird die AEAD-Ausgabe zurück in den Page Cache geschrieben — über eine Sicherheitssphäre hinweg.
  3. splice() als Privilege-Shift-Primitiv: splice(fd_in -> AF_ALG_socket) lässt den Angreifer dem Kernel Page-Cache-Pages einer Datei übergeben, auf die er nur Lesezugriff hat, während er kontrolliert, was die AEAD-Operation produziert.
  4. authencesn-Template als Trigger: das authencesn-Template (Encrypt-then-Authenticate with Sequence Number) durchläuft den In-Place-Buffer auf eine Weise, die den deterministischen 4-Byte-Überschreibvorgang in den Quell-Pages erzeugt.
  5. Page Cache prozess- und container-übergreifend geteilt: Linux hält genau eine Page-Cache-Kopie jeder Datei, unabhängig davon, wie viele Prozesse (oder Container auf demselben Knoten) sie lesen. Ein 4-Byte-Schreibzugriff aus einem sandboxed Container kann daher in Pages landen, die der Host-Kernel beim nächsten execve() an einen Host-Prozess ausliefert.
  6. Standardmäßig geladenes Modul auf jeder Distro: algif_aead wird autoloaded, sobald irgendein Prozess einen AF_ALG-AEAD-Socket öffnet. Die Angriffsfläche ist standardmäßig aktiv; eine Härtungsantwort, die sie entfernt, ist einfach (siehe Mitigation), aber nicht der Default.

Angriffsvektor

Der öffentliche PoC ist ein ~732-Byte-Python-Skript, das die unten skizzierten Schritte durchläuft. Die Skizze hier ist lediglich illustrativ und absichtlich nicht funktionsfähig — sie zeigt die Form des Angriffs, damit Verteidiger die relevanten Primitive erkennen.

# Schritt 1: Verfuegbarkeit des verwundbaren Moduls auf dem Ziel
# bestaetigen. Der Angreifer braucht das Modul nur ladbar - es laedt
# automatisch beim ersten AF_ALG-aead-socket()-Call. Als unprivilegierter
# Benutzer:
ls /sys/class/misc/cryptd 2>/dev/null
grep -E '^algif_aead ' /proc/modules || echo "Modul noch nicht geladen"

# Schritt 2: Ein privilegiertes Binary identifizieren, dessen Page
# Cache der Angreifer korrumpieren moechte. /usr/bin/su, /usr/bin/sudo,
# /usr/bin/passwd, /usr/bin/chage sind klassische SUID-Ziele. Der
# Dynamic Linker /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ist ein
# weiteres hochwertiges Ziel, weil er in jeden Executable gemappt wird.
file /usr/bin/su /usr/bin/sudo /usr/bin/passwd 2>/dev/null
ls -l /usr/bin/su

# Schritt 3: Der PoC oeffnet einen AF_ALG-aead-Socket, haengt das
# `authencesn(...)`-Template an und nutzt splice(), um den Page Cache
# von /usr/bin/su als AEAD-Quelle in den Kernel zu fuettern. Der Kernel
# schreibt die AEAD-Ausgabe zurueck in die Quell-Pages - den Page
# Cache von su.
python3 - <<'PY'
# *** NUR ILLUSTRATIV - KEIN FUNKTIONSFAEHIGER EXPLOIT ***
import socket, os
s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0)
s.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
# Echter PoC setzt Schluessel, IV, AAD und nutzt splice() mit
# /usr/bin/su als Source-fd, um das In-Place-AEAD-Primitiv zu
# treiben. Die Ausgabe der Operation landet im Page Cache von
# /usr/bin/su und korrumpiert die In-Memory-Kopie des SUID-Binaries.
# Die On-Disk-Datei bleibt unveraendert. Der Angreifer waehlt 4 Bytes,
# die einen Authentifizierungs-Branch in su zu unbedingtem Erfolg
# umwandeln oder eine von su beim Start gelesene Funktionszeiger-
# Tabelle hijacken.
s.close()
PY

# Schritt 4: Das korrumpierte Binary triggern. Der naechste exec von
# /usr/bin/su in irgendeinem Prozess mappt den manipulierten Page
# Cache, fuehrt den modifizierten Code-Pfad aus und hebt den Angreifer
# auf UID 0. Disk-Forensik sieht nichts.
/usr/bin/su -
id

Vereinfachte Sicht auf den Angriff:

Angreifer (unpriv. User / Container)         Linux-Kernel
   |                                                 |
   |  socket(AF_ALG) -> bind aead authencesn(...)    |
   |------------------------------------------------>|  algif_aead
   |                                                 |  geladen
   |                                                 |
   |  splice(fd=/usr/bin/su, AEAD_socket)            |  Source-SG
   |  source = Page-Cache-Pages von su               |  Liste zeigt
   |------------------------------------------------>|  auf /usr/bin/su
   |                                                 |  Page Cache
   |                                                 |
   |  AEAD-Operation in-place                        |  In-Place-Opt
   |  destination aliased source                     |  (2017er Bug)
   |------------------------------------------------>|  4-Byte
   |                                                 |  kontrollierter
   |                                                 |  Write zurueck
   |                                                 |  in su Page
   |                                                 |  Cache
   |                                                 |
   |  exec /usr/bin/su -                             |  Kernel mappt
   |------------------------------------------------>|  korrumpierte
   |                                                 |  Page beim
   |                                                 |  exec
   |<-- Root-Shell ----------------------------------|
   v                                                 v

Ausnutzung in freier Wildbahn

  • 2026-03-23 — Theori meldet den Bug privat an das Linux-Kernel-Security-Team, nachdem Xint Code (ihr KI-gestütztes Code-Analyse-Tool) das In-Place-Pattern in algif_aead.c markiert hat.
  • 2026-04-01 — Mainline-Fix landet als crypto: algif_aead - Revert to operating out-of-place (Commit a664bf3d603d).
  • 2026-04-22 — NVD veröffentlicht CVE-2026-31431 mit CVSS 7.8 und CWE-669; Per-LTS-Backports beginnen einzulaufen.
  • 2026-04-29 — Koordinierte öffentliche Disclosure; Theori, Wiz, Tenable, Microsoft, Bugcrowd und große Distros veröffentlichen Writeups.
  • 2026-04-30 — Ein funktionsfähiger ~732-Byte-Python-PoC erscheint auf GitHub im Repository copy-fail-CVE-2026-31431.
  • 2026-05-01CISA fügt CVE-2026-31431 dem Known Exploited Vulnerabilities Catalog hinzu; Frist für US-Behörden auf den 15.05.2026 gesetzt. Microsoft Defender liefert dedizierte Detections (Exploit:Linux/CopyFailExpDl.A, Behavior:Linux/CVE-2026-31431).
  • 2026-05-04 / 05 — Distro-Patch-Coverage verbreitert sich (Ubuntu, AlmaLinux, SUSE, Fedora, CloudLinux, Arch, Debian sid). Einige Long-Tail-Releases (Debian stable / Bookworm, mehrere RHEL-Minor-Streams) stehen zum Zeitpunkt der Veröffentlichung noch aus.

Post-Exploitation-Auswirkung

  1. Lokale Privilege Escalation auf Root: ein einziger exec eines manipulierten SUID-Binaries hebt den Angreifer auf UID 0.
  2. Container-Escape: weil der Page Cache kernelweit ist, landet ein 4-Byte-Schreibzugriff aus einem niedrig privilegierten Container in Pages, die der Host-Kernel an Host-Prozesse — und an andere Container, die dieselben Image-Layer teilen — ausliefert.
  3. Stealth by Design: es gibt keine On-Disk-Modifikation — AIDE, Tripwire, dm-verity, Paketmanager-Checksummen und audit-basierte File-Integrity-Monitore sehen alle ein sauberes Dateisystem.
  4. Reboot-resistent bis zum Reboot: die Modifikation persistiert für die Lebensdauer der Page (bis zur Cache-Eviction oder zum Reboot), sodass der Angreifer ein komfortables Fenster hat, um Credentials zu sammeln, On-Disk-Persistenz zu installieren oder zu pivotieren.
  5. Kubernetes- / Multi-Tenant-Blast-Radius: ein einzelner Mandant auf einem geteilten Knoten kann Host-Binaries korrumpieren, die andere Mandanten ausführen, und macht aus einer Pod-Kompromittierung eine Knoten-Kompromittierung.
  6. Supply-Chain-Pivot: eine bösartige Abhängigkeit in einer CI/CD-Pipeline kann auf einem Build-Host genau einmal exec aufrufen und bis zum Reboot über den Page Cache jedes nachgelagerte, auf diesem Host gebaute Artefakt besitzen.

Auswirkungsbewertung

Sofortige Auswirkung

  • Local-Auth, deterministisch, CVSS 7.8 ohne Race: die AC:L-/No-Race-Eigenschaft unterscheidet Copy Fail von Dirty Cow (CVE-2016-5195) und Dirty Pipe (CVE-2022-0847).
  • Universelle Linux-Exposition: jeder seit 2017 gebaute Kernel über jede gängige Distro hinweg.
  • Standardmäßig aktive Angriffsfläche: algif_aead lädt automatisch beim ersten AF_ALG-AEAD-Socket-Call.
  • Container-Escape-Primitiv: der Page Cache wird vom Host und allen Containern auf dem Knoten geteilt.
  • Öffentlicher PoC: ~732 Bytes Python; deterministisch; distro-übergreifend wiederverwendbar.
  • CISA KEV mit Frist 15.05.2026 für US-Behörden: regulatorische Frist, die starke Hinweise auf bestätigte Ausnutzungsperspektiven gibt.

Betroffene Versionen

Linux-Kernel-LinieVerwundbarBehoben in
4.14 — 5.10.xAlle Builds < 5.10.2545.10.254
5.11 — 5.15.xAlle Builds < 5.15.2045.15.204
5.16 — 6.1.xAlle Builds < 6.1.1706.1.170
6.2 — 6.6.xAlle Builds < 6.6.1376.6.137
6.7 — 6.12.xAlle Builds < 6.12.856.12.85
6.13 — 6.18.xAlle Builds < 6.18.226.18.22
6.19.xAlle Builds < 6.19.126.19.12
7.0 mainlineNicht betroffen (Fix gemerged)7.0

Distro-spezifische Paketversionen (Ubuntu USNs, RHSAs, Debian DSAs, AlmaLinux, SUSE) folgen den Upstream-LTS-Branches mit Stunden bis wenigen Tagen Verzögerung. Den Distro-Tracker prüfen, bevor ein Host als gepatcht deklariert wird.

Betroffene Umgebungen

  • Public-Cloud-Linux-VMs (Azure, AWS, GCP, OCI) auf jedem seit 2017 gebauten Linux-Marketplace-Image.
  • Kubernetes / OpenShift / EKS / AKS / GKE-Cluster mit verwundbaren Kerneln.
  • Mehrmandantenfähige Compute — geteilte SaaS-Laufzeiten, geteilte CI/CD-Runner, gehostete Notebooks (Jupyter, Colab-artig), akademische Cluster.
  • CI/CD-Build-Farmen, die nicht-vertrauenswürdigen Code ausführen (Third-Party-PRs, Dependency-Builds, Vendor-SDKs).
  • Container-Registry-Base-Images — Alpine- und Debian-/Ubuntu-Base-Layer tragen alle das verwundbare Kernel-Modul, sofern der Host-Kernel nicht gepatcht ist.
  • Embedded- / IoT-Linux mit Kerneln >= 4.14 — Router, NVRs, NAS-Appliances, Industrial Gateways, Automotive-Linux.
  • Entwickler-Workstations — Linux-Laptops sind exponiert, sobald der Benutzer nicht-vertrauenswürdigen Code ausführt (npm install, pip install, bösartige VS-Code-Erweiterungen).

Angreiferprofile

  • Cloud-Tenant-Angreifer: ein einziger Standpunkt auf einem mehrmandantenfähigen Knoten eskaliert auf Host-Root und erreicht die anderen Mandanten auf demselben Kernel.
  • Container-Escape-Operatoren: der Bug ist eines der saubersten bekannten Primitive, mit denen ein niedrig privilegierter Container zum Host ausbricht.
  • Initial-Access-Broker: jede Web-Shell / sshjack auf einem Linux-Host wird in Sekunden zu Root-Zugriff.
  • Ransomware-Affiliates: Kernel-Level-Zugriff umgeht EDR-User-Mode-Hooks und erlaubt Angreifern, Backup-Agents vor der Verschlüsselung zu deaktivieren.
  • CI/CD-Supply-Chain-Angreifer: eine bösartige Abhängigkeit kann auf einem Linux-Build-Host genau einmal exec aufrufen und bis zum Reboot über den Page Cache persistieren.
  • Insider-Bedrohungen: jeder eingeloggte Benutzer auf einem Linux-Server kann mit einem öffentlichen PoC und null forensischem Footprint auf der Disk zu Root werden.

Mitigationsstrategien

Sofortmaßnahmen (Priorität 1)

  1. Kernel auf ein gepatchtes LTS-Release upgraden und neustarten. Das ist der einzige dauerhafte Fix:

    # Laufenden Kernel und Zielversion identifizieren. Mit der Tabelle
    # oben vergleichen. Alles unterhalb des Fixed-Builds der LTS-Linie
    # ist exponiert.
    uname -r
    
    # Debian / Ubuntu (apt-basiert) - sicherstellen, dass das
    # -security-Pocket aktiviert ist.
    sudo apt-get update
    sudo apt-get install --only-upgrade linux-image-generic linux-image-$(uname -r | cut -d- -f3-)
    sudo reboot
    
    # RHEL / Rocky / Alma (dnf-basiert) - sicherstellen, dass RHSA /
    # Errata angewendet sind.
    sudo dnf update kernel kernel-core kernel-modules --security
    sudo reboot
    
    # SUSE (zypper-basiert)
    sudo zypper patch --category=security
    sudo reboot
  2. Hot-Mitigation, falls kein sofortiger Reboot möglich ist — das Modul algif_aead blacklisten, sodass AF_ALG-AEAD-Sockets es nicht autoloaden können:

    # Persistente Blacklist via modprobe.d. Mappt die Load-Aktion auf
    # /bin/false, sodass jeder zukuenftige Autoload-Versuch fehlschlaegt.
    # Reboot-fest.
    echo "install algif_aead /bin/false" | \
        sudo tee /etc/modprobe.d/disable-algif-aead.conf
    
    # Falls das Modul bereits geladen ist, entladen. Wenn ein Prozess
    # es nutzt (cryptsetup, firefox-esr in einigen Distros), schlaegt
    # rmmod fehl - dann die Aenderung fuer das naechste Wartungsfenster
    # einplanen.
    sudo rmmod algif_aead 2>/dev/null || \
        echo "Modul in Benutzung - Reboot zum Entladen einplanen"
    
    # Verifizieren, dass das Modul nicht mehr geladen ist.
    grep -qE '^algif_aead ' /proc/modules && \
        echo "WEITER GELADEN" || \
        echo "OK: algif_aead ist nicht geladen"
  3. Belt-and-Braces: AF_ALG-Socket-Erstellung kernel-weit blockieren:

    # In /etc/modprobe.d eintragen - verhindert, dass die gesamte
    # AF_ALG-Familie autoloaded wird. Cryptsetup, kTLS-Fallback-Pfade
    # und jeder Dienst, der AF_ALG oeffnet, schlaegt fehl; im
    # Wartungsfenster testen.
    echo "install af_alg /bin/false" | \
        sudo tee /etc/modprobe.d/disable-af-alg.conf
    
    # Fuer Container - seccomp-Profile anwenden, die socket()-Calls mit
    # domain == AF_ALG (38) verweigern. Docker / containerd /
    # Kubernetes koennen ein Custom-seccomp-Profil ausliefern, um dies
    # auf jedem Pod zu erzwingen.
  4. Jedes Geheimnis rotieren, das von einem verwundbaren Host aus erreichbar war, während das Expositionsfenster offen war: SSH-Host-Keys, Service-Account-Credentials, Kubeconfig-Tokens, IMDS-erreichbare Cloud-Provider-Role-Credentials. Davon ausgehen, dass container-geteilte Dateisysteme gelesen worden sein könnten.

  5. Jeden Linux-Host auf den laufenden Kernel-Version inventarisieren und unbekannte / Pre-2017- / Non-Mainline-Kernel als verdächtig behandeln:

    # Cluster-weites One-Shot-Inventar via Ansible / SSH-for-Schleife.
    # Die Tabelle oben ist der Vergleich. Alles unterhalb des Fixed-LTS-
    # Builds ist im Scope fuer Notfall-Patching.
    for h in $(cat hosts.txt); do
        printf "%-30s %s\n" "$h" "$(ssh $h 'uname -r')"
    done
  6. Für Container / Kubernetes: den Knoten-Kernel patchen. Pod-Images zu patchen behebt den Bug nicht — der Kernel wird vom Host geteilt.

Erkennungsmaßnahmen

Es gibt zwei Klassen von Signalen: (a) Exploitation-Versuche, beobachtbar über Kernel-Modul-Load-Events und ungewöhnliche AF_ALG-Socket-Aktivität; (b) Post-Exploitation, beobachtbar über verdächtige Privilegien-Übergänge nach AF_ALG-Nutzung.

# (a) Erstmaliges Laden von algif_aead in Umgebungen erkennen, in
# denen es zuvor nicht vorhanden war. dmesg / Kernel-Ringbuffer ist die
# einfachste Quelle. Per journald in das SIEM pipen.
journalctl -k --since "1 hour ago" | grep -i algif_aead

# (b) auditd-Regel, die jeden Prozess kennzeichnet, der einen AF_ALG-
# Socket oeffnet. AF_ALG = 38. Eine Baseline legitimer Nutzer
# (cryptsetup etc.) ist erforderlich - auf den langen Schwanz alarmieren.
sudo auditctl -a always,exit -F arch=b64 -S socket -F a0=38 \
    -k AFALG_SOCKET

# Aktuelle Audit-Treffer pruefen.
sudo ausearch -k AFALG_SOCKET --start recent

# (c) Nach Prozessen suchen, die AF_ALG genutzt und dann innerhalb von
# Sekunden ein SUID-Binary execvt haben - das ist die kanonische
# Exploit-Form. Falco / Tracee / eBPF-basierte Runtime-Security-Tools
# sind das richtige Vehikel fuer diese Regel.

SIEM-/Detection-Content (Falco-artige Skizze):

- rule: CopyFail Exploit Pattern
  desc: Prozess oeffnet AF_ALG-aead-Socket und execvt SUID innerhalb 5s
  condition: >
    (evt.type=socket and evt.arg.domain=AF_ALG and proc.uid != 0)
    and (evt.type=execve and proc.is_suid_binary=true
         and proc.parent.duration_ms < 5000)
  output: >
    CopyFail-artiges Verhalten: %proc.name pid=%proc.pid
    parent=%proc.pname uid=%user.uid binary=%proc.exepath
  priority: CRITICAL

Microsoft Defender for Endpoint Coverage (laut Microsoft-Writeup):

  • Exploit:Linux/CopyFailExpDl.A — file-basierte Detection des öffentlichen PoC.
  • Behavior:Linux/CVE-2026-31431 — Verhaltensbasierte Detection des Exploit-Patterns.
  • Microsoft Defender for Cloud alarmiert bei „Potential exploitation of copy-fail vulnerability” für Azure-Linux-VMs.

Langfristige Sicherheitsverbesserungen

  1. Default-Deny-Seccomp für AF_ALG: die meisten Workloads brauchen AF_ALG nicht. socket(AF_ALG, ...) in das Default-Seccomp-Profil deny-listen (Docker, containerd, Kubernetes, systemd-Unit RestrictAddressFamilies=).
  2. Aggressive Kernel-Patch-SLAs: ein 7-Tage-SLA für Kernel-CVEs ist die richtige Untergrenze; CISA-KEV-gelistete Kernel-CVEs verdienen 72 Stunden. Live-Patch-Tooling (kpatch, livepatch, kgraft) reduziert die Reboot-Kosten.
  3. Mandantentrennung = Knotentrennung: jeden mehrmandantenfähigen Linux-Knoten so behandeln, als könne eine Single-Tenant-Kompromittierung Root erreichen, weil Copy Fail (und die LPE-Klasse generell) genau das ermöglicht.
  4. Einschränken, wer Code auf Linux-Hosts ausführt: Entwickler-SSH-Zugriff, CI/CD-Runner mit Third-Party-Code und Jupyter-artige Notebooks sind die kanonischen lokalen LPE-Eintrittspunkte. Nicht-vertrauenswürdige Compute auf wegwerfbare, schnell rotierende VMs verlagern.
  5. Kernel-Versionen kontinuierlich inventarisieren: eine einzige Quelle der Wahrheit dafür schaffen, welche Hosts welche Kernel laufen lassen. Ohne das ist Patchen unmöglich.
  6. „Der Kernel ist gepatcht, aber der Page Cache nicht” üben: bis zum Reboot kann der Page Cache eines kompromittierten Hosts immer noch manipulierte Binaries enthalten. Patchen und neustarten.
  7. Kernel-seitige Krypto auf User-Space migrieren, wo praktikabel: Workloads, die AF_ALG rein für Hardware-Beschleunigung nutzen, können oft auf einen User-Space-OpenSSL-Build mit Engine-Mode-Hardware-Support umsteigen, sodass AF_ALG cluster-weit deaktiviert werden kann.

Warum ist das kritisch?

  1. Universelle Linux-Exposition: jede Distro, jeder Kernel ab 2017, jede Cloud, jeder Container.
  2. Deterministischer Exploit, keine Race: die Bug-Klasse ist angreiferfreundlicher als Dirty Cow oder Dirty Pipe.
  3. Geteilter Page Cache durchbricht Container-Isolation: ein 4-Byte-Schreibzugriff aus einem sandboxed Container erreicht den Host.
  4. Stealth by Design: keine On-Disk-Modifikation, keine File-Integrity-Alerts, keine Checksummen-Diskrepanz.
  5. Öffentlicher PoC + CISA KEV: die Hürde zur Waffenfähigkeit liegt am Boden; die föderale Patch-Frist spiegelt das wider.
  6. Standardmäßig aktive Angriffsfläche: das verwundbare Modul lädt automatisch beim ersten AF_ALG-AEAD-Socket-Call.
  7. Patch-and-Reboot, nicht Patch-only: In-Memory-State überlebt das Paket-Upgrade, bis der Kernel tatsächlich getauscht wurde.

Zeitstrahl und Disclosure

  • 2026-03-23 — Theori meldet den Bug privat an das Linux-Kernel-Security-Team; Mainline-Embargo beginnt.
  • 2026-04-01 — Mainline-Fix crypto: algif_aead - Revert to operating out-of-place landet (Commit a664bf3d603d).
  • 2026-04-22 — NVD veröffentlicht CVE-2026-31431 mit CVSS 7.8, CWE-669.
  • 2026-04-29 — Koordinierte Disclosure: Theori, Wiz, Tenable, Microsoft, Bugcrowd, Ubuntu, AlmaLinux, SUSE, CloudLinux, CERT-EU veröffentlichen Writeups und Patch-Guidance. Help Net Security und BleepingComputer-artige Outlets tragen die Nachricht.
  • 2026-04-30 — Öffentlicher ~732-Byte-Python-PoC erscheint auf GitHub.
  • 2026-05-01 — CISA fügt CVE-2026-31431 dem Known Exploited Vulnerabilities Catalog hinzu mit föderaler Frist 15.05.2026.
  • 2026-05-04 / 05 — Distro-Patch-Coverage verbreitert sich; Microsoft-Defender-Verhaltens-Detections live; Long-Tail-Releases (Debian stable / Bookworm, mehrere RHEL-Minor-Streams) zum Zeitpunkt der Veröffentlichung noch im Rollout.

Ressourcen und Referenzen

SEKurity Unterstuetzt Sie

Schwachstellen wie Copy Fail erinnern daran, dass „nur lokale Privilege Escalation” in modernen Linux-Umgebungen selten eine sinnvolle Einschränkung ist: jeder mehrmandantenfähige Knoten, jeder Kubernetes-Cluster, jeder CI/CD-Runner, der Third-Party-Code ausführt, jede Entwickler-Workstation, die ein bösartiges npm-Paket zieht, ist eine potenzielle Startrampe. Die Angriffsfläche ist der Kernel, der Blast Radius ist der Knoten, und das Stealth-Profil lautet „keine Disk-Spuren”. Wir helfen Organisationen, ihre tatsächliche Exposition über Linux-Flotten und Kubernetes-Umgebungen zu messen, zu validieren, dass Patches wirklich ausgeliefert und Hosts wirklich neugestartet wurden, und zu prüfen, ob eine Kernel-Level-Kompromittierung erkannt würde, bevor sie zu einem mehrmandantenfähigen Vorfall wird.

Unsere Leistungen

  • Penetration Testing: Webanwendungen, Mobile Apps (Android & iOS), SAP-Systeme, Active Directory
  • Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Engagements
  • Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.


Kontakt:

Website: www.sekurity.de

Anfragen: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH


Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Linux-Flotte ist unser Antrieb.


Quellen

Über den Autor

SEKurity Team

Offensive Security Experten

Das SEKurity GmbH Team besteht aus erfahrenen Penetrationstestern, Security-Forschern und Cybersecurity-Beratern. Unter dem Motto 'Your Trusted Adversaries' unterstützen wir Organisationen dabei, ihre IT-Sicherheit aus der Perspektive eines Angreifers zu bewerten und zu verbessern.

Verwandte Artikel