Warum sich „Copy Fail“ von früheren Exploits des Linux-Kernels unterscheidet

Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags

Die Kurzfassung

Was: Eine lokale Rechteausweitung unter Linux namens „Copy Fail“ (CVE-2026-31431), ein Logikfehler im AEAD-Authentifizierungspfad des Kernels, der vom Benutzerbereich aus über die AF_ALG-Socket-Schnittstelle und die Funktion `splice(2)` ausgenutzt werden kann.

Auswirkung: Ein veröffentlichter 732-Byte-Proof-of-Concept ermöglicht es, die Rechte eines lokalen Benutzers ohne Administratorrechte auf Root-Rechte zu erweitern – und zwar auf allen gängigen Linux-Distributionen, die anfällige Kernel verwenden.

Status: AlmaLinux, Ubuntu und andere Derivate stellen bereits gepatchte Kernel bereit. Die CISA hat CVE-2026-31431 am 1. Mai in ihren Katalog bekannter ausgenutzter Sicherheitslücken aufgenommen. CVSS 7.8 (HIGH).

Schweregrad: Lokaler Vektor, keine Berechtigungen erforderlich, keine Benutzerinteraktion, äußerst zuverlässige Ausnutzung. In vielen containerisierten oder gemeinsam genutzten Ausführungsumgebungen könnte eine erfolgreiche Ausnutzung aus einem Container heraus zu einer Kompromittierung auf Host-Ebene führen.

Handeln Sie jetzt: Schützen Sie betroffene Kernel unverzüglich. Unternehmen, die auf rebootless Live-Patching setzen, können den Exploit-Pfad neutralisieren, ohne auf Wartungsfenster oder Neustarts warten zu müssen. Andernfalls sollten Sie die vom Hersteller gepatchten Kernel so bald wie betrieblich möglich bereitstellen. Sollte beides nicht sofort möglich sein, deaktivieren Sie den anfälligen AF_ALG-AEAD-Pfad vorübergehend anhand der unten aufgeführten Abhilfemaßnahmen.

„Copy Fail“ ist deshalb von Bedeutung, weil es drei Eigenschaften vereint, die Verteidiger nur ungern zusammen sehen: eine große Reichweite, eine äußerst zuverlässige Ausnutzung und einen öffentlichen Proof-of-Concept, der am selben Tag wie die Offenlegung veröffentlicht wurde.

Bin ich betroffen?

Mit ziemlicher Sicherheit, es sei denn, Sie haben bereits ein Update installiert.

„Copy Fail“ betrifft Upstream-Linux ab Kernel 4.14, was bedeutet, dass fast jede aktiv gepflegte Unternehmensdistribution den anfälligen Code-Pfad übernommen hat:

Ubuntu-Versionen vor Resolute (26.04)
Red Hat Enterprise Linux 8, 9 und 10
AlmaLinux 8, 9, 10 und Kitten 10
Entsprechungen zu Rocky Linux, CentOS Stream und Oracle Linux
Fedora (aktuelle und frühere Versionen)
Debian Stable und Testing
openSUSE Tumbleweed und Leap
Die meisten nachgelagerten Rebuilds, einschließlich CloudLinux-Varianten

Größere Sorge bereitet jedoch die Gerätepopulation außerhalb aktiv gepflegter Unternehmensflotten: eingebettete Linux-Geräte, OEM-Kernel in Netzwerkgeräten, industrielle Systeme und Ausrüstungen am Ende ihrer Lebensdauer, für die möglicherweise nie wieder Patches bereitgestellt werden. Wenn für ein Gerät in letzter Zeit keine Kernel-Updates vom Hersteller bereitgestellt wurden, ist davon auszugehen, dass es dauerhaft ungeschützt bleibt.

Der anfällige Pfad hängt davon ab, ob der Kernel „algif_aead“ bereitstellt, was je nach Distribution auf eine von zwei Arten konfiguriert ist.

Kurze Überprüfung:


# Check if loaded as a module (Debian, Ubuntu, Arch-family)

lsmod | grep '^algif_aead '

# Check if built into the kernel (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Eine leere lsmod-Ausgabe ist nicht so unbedenklich, wie es den Anschein hat. Unter Debian, Ubuntu und Distributionen der Arch-Familie wird „algif_aead“ bei Bedarf automatisch geladen – ein Prozess ohne Sonderrechte kann das Laden bereits durch das Öffnen eines AF_ALG-Sockets mit einem passenden Algorithmusnamen auslösen. Bei Distributionen der RHEL-Familie wird der Code direkt in den Kernel kompiliert (CONFIG_CRYPTO_USER_API_AEAD=y) und erscheint unabhängig vom Status niemals in lsmod. Behandeln Sie den Host als anfällig, es sei denn, die Kernel-Befehlszeile setzt den AEAD-Initcall explizit auf die Blacklist oder der Kernel ist gepatcht.

Sie sind auch nicht geschützt, nur weil Ihre Distribution die Benutzernamensräume absichert. Der „Copy Fail“-Trigger erfordert nicht die Erstellung eines neuen Namensraums – die AF_ALG-Socket-Familie ist bei Standardinstallationen direkt von einem normalen, nicht privilegierten Prozess aus erreichbar.

Was ein Copy-Fail ist

„Copy Fail“ ist eine lokale Sicherheitslücke im Krypto-Subsystem des Linux-Kernels, die eine Ausweitung von Berechtigungen ermöglicht. Der Fehler liegt in der AEAD-Vorlage „authencesn“ – dem für IPsec ESN verwendeten Modus für authentifizierte Verschlüsselung – und kann ausgenutzt werden, wenn über AF_ALG in Verbindung mit splice(2) darauf zugegriffen wird.

Die ausnutzbare Kombination entstand aus drei Änderungen, die im Abstand von mehreren Jahren vorgenommen wurden und von denen keine für sich genommen fehlerhaft war. Die Vorlage „authencesn“, die 2011 zur Verarbeitung von IPsec-ESP-Erweiterten-Sequenznummern hinzugefügt wurde, nutzte den Zielpuffer des Aufrufers als Arbeitsspeicher – was harmlos war, solange nur die interne xfrm-Schicht des Kernels darauf zugriff. AF_ALG machte später AEAD-Operationen für den Userspace zugänglich. Im Jahr 2017 entfernte eine Leistungsoptimierung eine interne Kopie im AEAD-Pfad, wodurch der Kernel direkt auf der bereitgestellten Speicherseite arbeiten konnte. Die Kombination wurde gefährlich, als der Datenpfad von splice(2) gegen eine dateibasierte Page-Cache-Seite stammte.

Die Entdeckung selbst ist ein Grund dafür, warum dieser Fehler von Bedeutung ist. Der Theori-Forscher Taeyang Lee stellte die Hypothese auf, dass die Kombination von AF_ALG-Sockets mit `splice(2)` eine bislang kaum untersuchte Angriffsfläche im Zusammenhang mit der Herkunft von Scatterlist-Seiten schaffen könnte. Anstatt eine manuelle Überprüfung durchzuführen, speiste das Team diese einzeilige Hypothese in Xint Code ein – ihr KI-gestütztes Scansystem –, das auf den Ordner „crypto/“ ausgerichtet war. Etwa eine Stunde später wurde „Copy Fail“ als Befund mit dem höchsten Schweregrad gemeldet. Weitere Fehler mit hohem Schweregrad, die bei demselben Scan auftauchten, werden derzeit im Rahmen einer koordinierten Offenlegung bearbeitet.

Die Korrektur im Upstream ist eine direkte Rücknahme des ursprünglichen Optimierungs-Commits (a664bf3d603d). Dieses Detail ist wichtig, weil es verdeutlicht, wie solche Fehler oft die Überprüfung überstehen: Die Optimierung selbst erschien für sich genommen korrekt, doch angrenzende Ausführungswege wurden nie im Zusammenhang damit modelliert.

Warum „Copy Fail“ anders ist

Dies ist der Teil, auf den Sie besonders achten sollten, wenn Sie den stetigen Strom von Linux-LPEs in den letzten zehn Jahren verfolgt haben – Dirty COW, Dirty Pipe, StackRot, Dirty Frag und andere aus derselben Familie.

„Dirty Pipe“ war von Bedeutung, weil es die Beschädigung des Seiten-Caches in eine praktikable Methode zur Rechteausweitung verwandelte. Die meisten Fehler dieser Art waren jedoch nach wie vor mit operativen Hindernissen verbunden. Sie waren mit Race-Conditions behaftet, von der Kernel-Version abhängig, erforderten ungewöhnliche Module, wurden durch Namespace-Einschränkungen blockiert oder waren so unzuverlässig, dass Verteidiger realistisch gesehen Zeit gewinnen konnten.

„Copy Fail“ beseitigt einen Großteil dieser Hindernisse.

Der veröffentlichte Exploit funktioniert Berichten zufolge mit nur geringen oder gar keinen Anpassungen auf allen gängigen Linux-Distributionen, die von den Forschern getestet wurden. Es gibt keine umfangreiche Offset-Tabelle für einzelne Distributionen und keine langwierige Logik zur Zielauswahl. Der Exploit-Pfad ist ungewöhnlich portabel.

Das Sicherheitsrisiko ist zudem ungewöhnlich weitreichend. Die anfällige Optimierung wurde bereits 2017 in die vorgelagerten Linux-Versionen integriert und hat sich auf Kernel mit langfristigem Support ausgeweitet, die sich bis heute innerhalb der Support-Zeiträume der Anbieter befinden. Dazu gehören Unternehmenssysteme, eingebettete Anwendungen, Appliances und festgelegte Infrastrukturen, deren Aktualisierung Unternehmen oft über Jahre hinweg aufschieben.

Vor allem aber ist „Exploitation“ äußerst zuverlässig. Viele moderne Kernel-LPEs weisen probabilistisches Verhalten auf – Heap-Shaping, Race-Timing oder komplexe Ketten, an denen mehrere Primitive beteiligt sind. „Copy Fail“ ist dagegen vergleichsweise unkompliziert. Die Versuche sind entweder erfolgreich oder schlagen eindeutig fehl, ohne den Host zu destabilisieren.

Auch die zugängliche Angriffsfläche ist ungewöhnlich weit verbreitet. Im Gegensatz zu Nischenmodulen, die bei einigen aktuellen Kernel-Exploits eine Rolle spielen, ist „algif_aead“ in den gängigen Distributionen weit verbreitet und wird entweder fest eingebunden oder bei Bedarf automatisch geladen. Standardinstallationen auf Servern, Desktops und Container-Hosts bieten häufig einen zugänglichen Pfad von einem Prozess ohne Sonderrechte zum anfälligen Code.

Das Ergebnis ist, dass viele herkömmliche Annahmen, die darauf abzielen, „Zeit zu gewinnen“, hier wenig helfen. In der Praxis lässt sich eine sinnvolle Risikominderung nur durch das Patchen des Kernels oder das Sperren des Zugriffs auf den anfälligen Pfad erreichen.

Warum moderne Infrastruktur das Problem noch verschlimmert

Der Begriff „lokaler Angreifer“ bezog sich früher auf einen relativ begrenzten Kontext – physischen Zugriff, gestohlene SSH-Zugangsdaten oder eine zuvor erfolgte Kompromittierung des Netzwerks.

Diese Definition spiegelt nicht mehr wider, wie Linux-Infrastrukturen im Jahr 2026 funktionieren.

Moderne Infrastruktur basiert auf gemeinsamer Ausführung. Kubernetes-Knoten hosten Workloads aus verschiedenen Namespaces gemeinsam. CI/CD-Runner führen Pull-Request-Code von externen Mitwirkenden aus. Cloud-Notebooks, Entwickler-Sandboxes, mandantenfähige SaaS-Plattformen und Build-Systeme führen regelmäßig teilweise vertrauenswürdigen Code auf gemeinsam genutzten Kerneln aus.

In diesem Umfeld entspricht der Begriff „lokal“ zunehmend dem, was früher unter „internetfähig“ verstanden wurde.

Eine bösartige npm-Abhängigkeit, die in die CI gelangt, eine Webanwendung mit RCE, die eine Shell mit geringen Berechtigungen gewährt, ein kompromittiertes Entwicklerkonto oder eine unvollständige Container-Escape-Kette – all dies kann zum Sprungbrett für vollständigen Root-Zugriff werden. Copy Fail verkürzt den Weg vom ersten Einfallstor bis zur vollständigen Kompromittierung auf Kernel-Ebene.

Die Sicherheitslücke allein lässt sich nicht aus der Ferne ausnutzen. Ein Angreifer benötigt nach wie vor die Möglichkeit, irgendwo auf dem Host Code auszuführen. In Umgebungen mit gemeinsamer Ausführung ist das Angebot an potenziellen Einfallstoren jedoch bereits so groß, dass diese Unterscheidung weniger wichtig ist als früher.

Wie der Exploit tatsächlich funktioniert

Linux stellt die Krypto-Funktionen des Kernels über AF_ALG-Sockets für den Userspace bereit. Ein Prozess kann Algorithmen wie authencesn(hmac(sha256),cbc(aes)) anfordern und Daten über Standard-Lese-/Schreibschnittstellen übermitteln.

Die Optimierung von 2017 zielte darauf ab, die Leistung zu verbessern, indem unnötige interne Kopiervorgänge bei bestimmten AEAD-Operationen vermieden wurden. Anstatt Eingabedaten in temporäre Puffer zu kopieren und die Ergebnisse wieder zurückzukopieren, konnte der Kernel in manchen Fällen direkt auf der bereitgestellten Speicherseite arbeiten.

Diese Annahme trifft nicht mehr zu, wenn die Eingabe über `splice(2)` von einem dateibasierten Deskriptor stammt. Im Gegensatz zu gewöhnlichen Lese- und Schreibvorgängen kann `splice` Verweise auf bereits im Cache befindliche Seiten übertragen, anstatt Daten zu kopieren. Der Krypto-Pfad behandelte diese Seiten fälschlicherweise als beschreibbaren Arbeitsspeicher und führte eine In-Place-Transformation an ihnen durch.

Dieses Verhalten ist spezifisch für authencesn. Andere Standard-AEAD-Algorithmen – GCM, CCM, reguläres authenc – beschränken ihre Schreibvorgänge auf den legitimen Ausgabebereich. Die Vorlage „authencesn“, die ursprünglich für einen internen IPsec-Codepfad geschrieben wurde, der beide Enden des Vorgangs steuerte, behandelt die Ziel-Scatterlist des Aufrufers als temporären Speicherbereich. Als AF_ALG diesen Pfad dem Userspace zugänglich machte und Splice darin dateibasierte Seiten einfügte, entstand eine Primitive, die pro Vorgang 4 kontrollierte Bytes in den Seitencache jeder lesbaren Datei schreibt.

Jeder Vorgang schlägt tatsächlich fehl – die HMAC-Überprüfung schlägt fehl, da der Chiffretext gefälscht ist, und recvmsg() gibt einen Fehler an den Aufrufer zurück. Der 4-Byte-Schreibvorgang wird dennoch ausgeführt. Durch Wiederholen des Vorgangs an ausgewählten Offsets schleust ein Angreifer Shellcode in das zwischengespeicherte Image einer Setuid-Binärdatei wie beispielsweise /usr/bin/su ein.

Der Inhalt der Festplatte ändert sich nie. Die Änderung besteht nur im Arbeitsspeicher, bis die zwischengespeicherte Seite aus dem Speicher verdrängt wird. Tools zur Überprüfung der Dateisystemintegrität, Datei-Hashing und Festplattenforensik stellen daher möglicherweise nichts Ungewöhnliches fest, obwohl das zwischengespeicherte ausführbare Image lange genug verändert war, damit der Angreifer es als Root ausführen konnte.

Der öffentliche PoC folgt einer relativ kurzen Kette:

Öffne einen AF_ALG-Socket, der an authencesn gebunden ist
Öffnen Sie eine Setuid-Binärdatei wie beispielsweise /usr/bin/su zum Lesen
Verwende „splice“, um die zwischengespeicherten Seiten des Ziels in den AF_ALG-Pfad zu verschieben
Löse die In-Place-Verschlüsselungsoperation aus, die pro Aufruf 4 vom Angreifer gewählte Bytes schreibt
Wiederhole dies über alle Offsets hinweg, um Shellcode in das zwischengespeicherte Image einzuschleusen
Führen Sie die geänderte, zwischengespeicherte Binärdatei als Root aus

Neben dem ursprünglichen Python-PoC gibt es bereits Neuimplementierungen in C, Go und auf arm64. Eine ältere Python-Version auf dem Zielsystem stellt kein nennenswertes Hindernis dar. Der ursprüngliche Bericht von Xint/Theori bleibt die beste technische Referenz für Verteidiger, die tiefere Einblicke in die Implementierungsdetails benötigen.

Milderung

Der sicherste Weg zur Behebung des Problems besteht darin, den laufenden Kernel unverzüglich zu schützen. Es gibt drei praktische Möglichkeiten, das Risiko zu verringern; diese sind hier nach Geschwindigkeit und Auswirkungen auf den Betrieb geordnet.

1. Patches ohne Neustart (am schnellsten, keine Ausfallzeiten)

KernelCare veröffentlichte Live-Patches für „Copy Fail“ für unterstützte, im Einsatz befindliche Unternehmenskernel, noch bevor mehrere nachgelagerte Distributionen aktualisierte Kernel-Paketversionen bereitstellten.

Der „Rebootless“-Patch neutralisiert die Sicherheitslücke im laufenden Kernel, ohne dass ein sofortiger Neustart erforderlich ist – wodurch das Sicherheitsrisiko sofort verringert wird, anstatt auf den nächsten Wartungszyklus zu warten.

Einige Schwachstellenscanner melden möglicherweise auch nach einem Patch ohne Neustart vorübergehend weiterhin betroffene Kernel-Versionen, da die Paketversionen der Anbieter und die Erkennungslogik der Scanner hinter dem geschützten Status des laufenden Kernels zurückbleiben können.

Für Unternehmen, die eine verfügbarkeitskritische Infrastruktur verwalten, ist dies der schnellste Weg zur Fehlerbehebung.

Sie sind noch kein KernelCare-Kunde? Bis Ende Juni gelten für Neukunden Sonderkonditionen. Erfahren Sie hier mehr über KernelCare.

2. Installieren Sie einen gepatchten Kernel und starten Sie den Computer neu

Die übliche Vorgehensweise zur Behebung des Problems besteht darin, das vom Hersteller bereitgestellte gepatchte Kernel-Paket zu installieren und die betroffenen Systeme neu zu starten.

Unternehmen sollten die Verfügbarkeit von Patches für ihre Distribution überprüfen und den Umgebungen Vorrang einräumen, in denen teilweise vertrauenswürdiger Code ausgeführt werden kann – darunter Kubernetes-Knoten, CI/CD-Runner, gemeinsam genutzte Hosts, Entwicklerinfrastruktur und mandantenfähige Anwendungsplattformen.

3. Vorübergehende manuelle Abhilfe (falls das Installieren des Patches noch warten muss)

Wenn weder Live-Patching noch Fenster für einen sofortigen Neustart verfügbar sind, kann die Angriffsfläche von AF_ALG AEAD vorübergehend über die Kernel-Befehlszeile deaktiviert werden.

Bitte lesen Sie dies zuerst: Die unten aufgeführten Abhilfemaßnahmen beseitigen die Angriffsfläche für AF_ALG-AEAD-Angriffe. Bei den meisten Workloads kommt es zu einer kontrollierten Leistungsminderung – dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS und SSH sind davon nicht betroffen. Anwendungen, die explizit die OpenSSL-afalg-Engine, Hardware-Krypto-Offload über AF_ALG oder direkte AEAD-Socket-Bindung nutzen, können fehlschlagen oder an Leistung einbüßen. Bitte vor einer breiten Bereitstellung überprüfen.

Ermitteln Sie zunächst, wie „algif_aead“ in Ihrem Kernel bereitgestellt wird:

# Loadable module (Debian, Ubuntu, Arch family)

grep -qE '^algif_aead ' /proc/modules && echo "loaded as module" || echo "not currently loaded"

# Built-in (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle Linux, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Wenn der Befehl „config grep“ den Wert „y“ zurückgibt, wird der Code in den Kernel kompiliert. „modprobe blacklists“ und „rmmod“ scheinen zwar ohne Fehlermeldung erfolgreich zu sein, bieten jedoch keinen Schutz.

Allgemeine Abhilfe (funktioniert sowohl bei Modul- als auch bei integrierten Kerneln) – Deaktivieren Sie den initcall über die Kernel-Befehlszeile:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

sudo reboot

Überprüfen Sie nach dem Neustart Folgendes:

grep -o 'initcall_blacklist=algif_aead_init' /proc/cmdline

Eine leere Ausgabe bedeutet, dass der Parameter nicht übernommen wurde – überprüfe „grubby“ erneut und vergewissere dich, dass tatsächlich ein Neustart stattgefunden hat.

Abhilfe nur für ladbare Module (Debian, Ubuntu, Arch und ähnliche) – nützlich, wenn ein Neustart hinausgezögert werden muss:

sudo sh -c 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif_aead.conf'

sudo rmmod algif_aead 2>/dev/null || true

Bestätigen:

grep -qE '^algif_aead ' /proc/modules && echo "still loaded" || echo "not loaded"

Verlassen Sie sich auf Hosts der RHEL-Familie nicht auf diesen Ansatz. Beide Befehle geben unabhängig davon, ob das System integriert ist, einen Erfolg zurück, was ein trügerisches Gefühl der Sicherheit vermittelt.

Bei Verdacht auf Missbrauch sollten Sie die im Cache gespeicherten Seiten löschen, damit die geänderten ausführbaren Seiten erneut von der Festplatte geladen werden:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Hier geht es um Eindämmung, nicht um Beseitigung. Wenn ein Angreifer bereits Root-Zugriff erlangt hat, könnten an anderer Stelle im System bereits Mechanismen zur Aufrechterhaltung der Präsenz vorhanden sein.

SELinux und AppArmor können die Erstellung von AF_ALG-Sockets technisch zwar blockieren, jedoch nur, wenn sie so konfiguriert sind, dass sie dies für nicht eingeschränkte oder weitreichend zugelassene Prozesse verweigern. Die Standardrichtlinien aller gängigen Distributionen lassen dies zu. Betrachten Sie MAC-basierte Einschränkungen als eine Sicherheitsmaßnahme für flottenweite Rollouts, nicht als Sofortmaßnahme.

Für Kubernetes-Operatoren hat OVHcloud einen Ansatz zur Risikominderung mittels DaemonSets für verwaltete Cluster veröffentlicht. Das gleiche Verfahren lässt sich allgemein auf Kubernetes-Umgebungen anwenden, in denen koordinierte Neustarts während Notfallmaßnahmen nur schwer durchführbar sind.

Falls AF_ALG nicht deaktiviert werden kann, weil Workloads davon abhängig sind, bleiben als Optionen nur die Isolierung nicht vertrauenswürdiger lokaler Ausführungen oder das Patchen des Kernels ohne Neustart, bis Wartungsfenster zur Verfügung stehen.

Für Nutzer von KernelCare Enterprise wurden Patches für „Copy Fail“, die ohne Neustart installiert werden können, für bestehende, unterstützte Enterprise-Kernel veröffentlicht, noch bevor mehrere nachgelagerte Distributionen aktualisierte Versionen der Kernel-Pakete herausbrachten.

Infolgedessen melden einige Scanner möglicherweise vorübergehend weiterhin anfällige Kernel-Versionen, selbst wenn der aktuell ausgeführte Kernel bereits durch einen Patch ohne Neustart geschützt wurde. Es wird erwartet, dass in Kürze aktualisierte Kernel-Builds der Hersteller sowie eine entsprechende Erkennungslogik folgen werden.

Erkennung

Es gibt keine zuverlässige Signatur zur Erkennung von „Copy Fail“ nach einer Kompromittierung.

Bei einer erfolgreichen Ausnutzung bleiben keine Spuren auf der Festplatte zurück, das Syscall-Muster ähnelt legitimen Verschlüsselungsvorgängen im Userspace, und die zwischengespeicherten Änderungen verschwinden, sobald die Seiten aus dem Arbeitsspeicher ausgelagert werden.

In den meisten Umgebungen wird eine nachträgliche Überprüfung schwierig sein, es sei denn, Syscall-Telemetrie, eBPF-Instrumentierung oder detaillierte Audit-Protokollierung waren bereits vor dem Angriff aktiviert.

Zu den wichtigsten zu überwachenden Signalen gehören:

Das Modul „algif_aead“ wird unerwartet auf Systemen geladen, auf denen keine AF_ALG-Verbraucher bekannt sind
Ungewöhnliche Ausführung von „su“ oder „sudo“ kurz nach einer AF_ALG-Aktivität
splice(2)-Operationen, die auf AF_ALG-Sockets von dateibasierten Deskriptoren abzielen

Erkennungsregeln, die auf Python-Ausführungsmuster ausgerichtet sind, lassen andere Implementierungen außer Acht – C-, Go- und arm64-Neuimplementierungen des Exploits sind öffentlich zugänglich und erfordern kein Python auf dem Zielsystem. Es handelt sich hierbei um Heuristiken, nicht um Garantien. Jedes System, auf dem nicht vertrauenswürdige Benutzer während des Sicherheitslückenzeitraums Shell-Zugriff hatten, sollte als potenziell kompromittiert betrachtet werden.

Checkliste für priorisierte Sanierungsmaßnahmen

Wenden Sie einen Patch ohne Neustart an oder stellen Sie unverzüglich einen gepatchten Kernel bereit. Nutzer von KernelCare Enterprise können den Exploit-Pfad auf unterstützten, laufenden Kerneln ohne Neustart neutralisieren. Andernfalls installieren Sie das vom Hersteller gepatchte Kernel-Paket und starten Sie die betroffenen Systeme neu.
Falls das Installieren des Patches noch warten muss, wenden Sie die Abhilfemaßnahme „initcall_blacklist=algif_aead_init“ in der Kernel-Befehlszeile an, nachdem Sie die Auswirkungen auf die Arbeitslast überprüft haben. Die in einigen früheren Sicherheitshinweisen beschriebene, auf „modprobe“ basierende Abhilfemaßnahme funktioniert bei Kerneln der RHEL-Familie nicht.
Überprüfen Sie Umgebungen, in denen teilweise vertrauenswürdiger Code ausgeführt werden kann – CI-Systeme, Shared-Hosting-Umgebungen, Kubernetes-Knoten, Entwicklerinfrastrukturen und SaaS-Worker-Flotten.
Achten Sie ab der Bekanntgabe am 29. April auf verdächtige Aktivitäten von AF_ALG.
Starten Sie die gepatchten Systeme neu, um den anfälligen Laufzeitzustand und die zwischengespeicherten Seiten zu löschen.

Warum diese Art von Käfern immer wieder auftaucht

„Copy Fail“, „Dirty Pipe“ und „Dirty Frag“ unterscheiden sich zwar in den Implementierungsdetails, folgen jedoch demselben Grundmuster: leistungsorientierte Fast-Paths, die falsche Annahmen hinsichtlich der Speicherzuordnung treffen.

In jedem Fall betraf ein Schreibvorgang eine Seite, von der der Kernel fälschlicherweise annahm, dass sie sicher geändert werden könne.

Der Seitencache wird immer wieder zum Opfer, da er bewusst gemeinsam genutzt wird. Jeder Prozess, der eine Datei liest, greift auf dieselbe zugrunde liegende physische Seite zu. Ein einziger unbeabsichtigter Schreibvorgang auf diese gemeinsam genutzte Seite kann für privilegierte Binärdateien sichtbar werden, die von dort aus ausführbaren Code laden.

Die Lösung besteht nicht einfach darin, „die Optimierung einzustellen“. Moderne Systeme sind auf diese Leistungswege angewiesen. Auch die dauerhafte Deaktivierung des Moduls, das zufällig in den jüngsten Exploit verwickelt war, ist keine langfristige Lösung.

Die grundlegendere Lösung besteht darin, strengere Garantien für die Seitenbesitzrechte in allen Bereichen der Kernel-Speicherverwaltung durchzusetzen – eine Arbeit, die die Upstream-Betreuer bereits in Angriff genommen haben, die jedoch nur langsam vorankommt, da sie einige der leistungsempfindlichsten Subsysteme des Kernels betrifft.

„Copy Fail“ wird wahrscheinlich nicht die letzte Sicherheitslücke dieser Art sein.

Und Linux stellt möglicherweise nur den sichtbaren Teil des Problems dar.

„Copy Fail“ blieb fast ein Jahrzehnt lang in intensiv geprüftem Open-Source-Code verborgen und wurde dann innerhalb von etwa einer Stunde durch einen KI-gestützten Scanner mit einer einzigen Bedienereingabe aufgedeckt. Linux ist der Teil des Stacks, der gescannt wird, weil er gescannt werden kann – offen und von jedem. Die weitaus größere Oberfläche aus proprietärer Firmware, Hersteller-Kerneln, veralteten Protokollen und Chip-Mikrocode beruhte in der Vergangenheit auf der Annahme, dass versteckter Code auch versteckte Fehler bedeute. Wie Igor Seletskiy in „Open Source is the Tip of the Iceberg“ argumentiert, verliert diese Annahme nun an Gültigkeit. „Copy Fail“ ist einer der ersten Datenpunkte; es wird nicht einer der letzten sein.