CopyFail (CVE-2026-31431): Funktionsweise, Erkennung und Schutzmaßnahmen für Linux-Systeme

Am 29. April 2026 wurde die Schwachstelle CVE-2026-31431 mit dem Namen „Copy Fail“ öffentlich bekannt gemacht.

Sie betrifft viele Linux-Distributionen mit betroffenen Kernel-Versionen. Der Angriff nutzt hierbei drei Kernel-Komponenten.

Wie funktioniert der Angriff

AF_ALG ist eine Socket-basierte Kernel-Schnittstelle für Kryptografie, über die unprivilegierte Nutzer kryptografische Operationen wie Verschlüsselung und Hashing ausführen können, ohne Root-Rechte zu benötigen. Über diese Schnittstelle ist unter anderem auch das Template authencesn erreichbar, das mehrere kryptografische Verfahren kombiniert. In diesem befindet sich der Logikfehler. Mithilfe von splice() können Daten aus einer Datei ohne Kopieren direkt aus dem Page Cache in den Krypto-Socket übergeben werden, wobei lediglich Referenzen auf die bestehenden Speicherseiten verwendet werden. Durch eine Kernel-Optimierung zeigen Eingabe- und Ausgabepuffer dabei auf dieselben Speicherseiten. Wenn authencesn diese Daten verarbeitet, schreibt es aufgrund eines Fehlers vier Bytes außerhalb des vorgesehenen Puffers und damit direkt in den ursprünglichen Speicherbereich zurück, aus dem die Eingabe stammt.

Durch den Fehler wird einem unprivilegierten lokalen Nutzer ermöglicht, einen eingeschränkt kontrollierbaren 4-Byte-Schreibzugriff in den Page Cache von Dateien auszulösen, für die der Angreifer Leseberechtigungen besitzt. Der Page Cache ist dabei der Puffer, den der Linux-Kernel zwischen Arbeitsspeicher und Datenträger nutzt. Liest ein Prozess eine Datei, wird deren Inhalt einmalig in den RAM geladen und dort zwischengespeichert. Genau diese im Speicher liegende Kopie wird durch den Angriff verändert, nicht jedoch die Datei auf der Festplatte selbst. Besonders kritisch ist, dass diese Änderungen nicht als „dirty“ markiert werden und somit weder vom Writeback-Mechanismus noch von klassischen Integritätsprüfungen erkannt werden. Da der Page Cache systemweit und auch über Container-Grenzen hinweg geteilt wird, können die manipulierten Daten von anderen Prozessen übernommen werden.

Ein lediglich 732 Byte großes Python-Skript, das nur Standardbibliotheken nutzt, reicht aus, um diesen Mechanismus auszunutzen und auf praktisch allen gängigen Linux-Distributionen Root-Rechte zu erlangen.

Warum ist die CVE so gefährlich?

Der Exploit muss nicht als schadhaftes Programm in Erscheinung treten. Jede Anwendung, jedes automatisierte Script, jedes kompromittierte Paket-Update kann ihn heimlich mittransportieren. Der Nutzer sieht dabei eine normal laufende Software. Im Hintergrund werden Root-Rechte erlangt, persistente Backdoors eingerichtet, Zugangsdaten ausgelesen oder andere Systeme im Netzwerk angegriffen.

Die Exploit Kette erklärt:

1. AF_ALG-Socket einrichten
   Der Angreifer öffnet einen AF_ALG-Socket und bindet ihn an das Template authencesn(hmac(sha256),cbc(aes)). Das ist ein normaler, unprivilegierter Syscall. Der Kernel stellt diese Schnittstelle bereit, damit Userspace-Programme die Krypto-Hardware nutzen können (z. B. für IPsec). Danach wird ein „Request Socket“ per accept() erzeugt, über den die eigentlichen Krypto-Operationen laufen.
   
   authencesn(hmac(sha256),cbc(aes)) ist eine Kernel-interne Notation ür ein zusammengesetztes kryptografisches Template. Es beschreibt, welche zwei Verfahren authencesn kombiniert und wie.
   
2. Zieldatei in den Socket einspeisen
   Normalerweise würde man mit write()in einen Socket schreiben, da die Bytes dabei kopiert werden.splice() übergibt hingegen einen Zeiger auf die bereits im Speicher gecachten Seiten der Datei (Page Cache), ohne sie zu kopieren. Der Angreifer öffnet /usr/bin/su (lesbar für jeden) und spleißt einen bestimmten Bereich dieser Datei in eine Pipe und von dort in den AF_ALG-Socket.
   
3. Den 4-Byte-Schreibvorgang platzieren
   Vor dem eigentlichen Krypto-Aufruf schickt der Angreifer per sendmsg() die AAD (Associated Authenticated Data) an den Socket. In den Bytes 4–7 der AAD stecken die 4 Bytes, die später in die Zieldatei geschrieben werden sollen. Beispielsweise der Beginn eines Shellcode-Opcodes.
   
   Im nächsten Schritt wird recvmsg() aufgerufen, was die AEAD-Entschlüsselung auslöst. Im Inneren von authencesn läuft nun folgendes ab:
   
   Der Algorithmus liest bestimmte Bytes (ESN) aus den Zusatzdaten (AAD). Anschließend werden 4 dieser Bytes, die von einem Angreifer kontrolliert werden können, an eine bestimmte Speicherstelle geschrieben. Aufgrund einer Optimierung im Kernel seit 2017 zeigt diese Speicherstelle jedoch nicht mehr auf einen sicheren Puffer, sondern auf eine im Speicher befindliche Datei, zum Beispiel /usr/bin/su im sogenannten Page Cache. Dadurch kann ein Angreifer gezielt 4 Bytes in den Kernel-Speicher schreiben. Zwar erkennt das System danach, dass die Nachricht ungültig ist, weil die HMAC-Prüfung fehlschlägt, und gibt einen Fehler zurück. Allerdings ist die Schreiboperation zu diesem Zeitpunkt bereits erfolgt und wird nicht rückgängig gemacht. Dadurch entsteht die Möglichkeit, trotz fehlgeschlagener Integritätsprüfung Daten im Speicher zu verändern.
   
4. Ausführung – execve als Zünder
   Wenn alle Chunks geschrieben sind, ruft der Angreifer execve("/usr/bin/su") auf.Der Kernel sucht nun die Datei im Page Cache und findet sie dort sofort, denn die Seiten sind bereits geladen. Er lädt den (im Page Cache korrumpierten) Code und führt ihn aus. Da su das setuid-Bit gesetzt hat, wechselt der Kernel beim Start automatisch auf UID 0 (root), unabhängig davon, wer die Datei aufruft.Der eingebettete Shellcode läuft jetzt mit Root-Rechten.

Nachstellung Exploit und Analyse im SIEM

Ein Exploit wurde unter diesem Link veröffentlicht und getestet. Dabei manipuliert das Pytho Skript den Kernel_page-Cache der Ziel Binärdatei (/usr/bin/su oder ein anderes setuid-Binary) direkt im Speicher. Da setuid-Binärdateien mit root-Rechten ausgeführt werden, reicht es, deren Code im Cache zu überschreiben. Der nächste Aufruf von su führt dann den manipulierten Code als uid=0 (root) aus.

Über Sysmon ist leider nur erkennbar, dass ein privilegierter Nutzer (test) eine Shell startet, und diese Shell läuft als root läuft. Dies führt leider oft zu false positves, da auch legitime Tools wie Ansible sehr viele kurzlebige Shells als root spwant. Aus diesem Grund ist das Log kein Indikator für einen Exploit.

Eine Alternative zur Erkennung des Exploits ist auditd. Dieses überwacht Sicherheitsereignisse auf Linux, unter anderem SOCKET-Events und Funtkionsaufrufe.

Dafür benötigt es Regeln zu Überwachung, die wie folgt aussehen könnten:

Dadurch ist es möglich, Sessions zu identifizeren in denen af_alg_socket + splice + setuid_exec zusammen auftauchen:

Das Log sagt folgendes aus.

Im weiteren Verlauf kann anhand der Session 3 die folgenden Aufrufe gesucht werden, um den Exploit zu bestätigen.

Handlungsempfehlungen:

1.AF_ALG-Socket Erstellung blockieren:

Das Kernel-Modul algif_aead sollte deaktiviert bzw. nicht geladen werden, sofern es im System nicht zwingend benötigt wird. Dieses Modul stellt die Schnittstelle bereit, über die AEAD-Algorithmen via AF_ALG-Sockets aus dem Userspace angesprochen werden können. Wird das Modul nicht geladen, ist es für Nutzer nicht möglich, entsprechende Sockets zu öffnen. Dadurch wird der gesamte beschriebene Angriffsweg effektiv unterbunden, da bereits der erste Schritt, das Binden des Sockets, fehlschlägt. Mehr dazu.

2. Bei manchen Distributionen ist algif_aead kein Modul, sondern fest im Kernel einkompiliert (Beispiel Red Hat). Die Lösung dafür ist das Blockieren des Aufrufs der Kernel-Funktion. Dafür muss man beim Boot dem Kernel folgenden Parameter übergeben: initcall_blacklist=algif_aead_init. Mehr dazu.

3. Kernel Paket der genutzten Distribution patchen