Linux-TCP-Lücke: Ubuntu- und RHEL-Fixes nach Exploit-Behauptung offen

Linux-TCP-Lücke: Ubuntu- und RHEL-Fixes nach Exploit-Behauptung offen

Füge CyberWorldOpsals bevorzugte Quelle bei Google hinzu
Linux-TCP-Lücke: Ubuntu- und RHEL-Fixes nach Exploit-Behauptung offen
Schwachstellen

Illustration mit KI erzeugt

Ubuntu- und Red-Hat-Enterprise-Linux-Anwender warteten am 29. Oktober noch auf Distributionsfixes für CVE-2026-98432, eine Netzwerklücke im Linux-Kernel, mit der Anthropic nach eigenen Angaben Befehle aus der Ferne als Root ausgeführt hat. Die Demonstration des Unternehmens richtete sich gegen Server mit einem Multipath-TCP-Listener. Es ist nicht belegt, dass dieselbe Übernahme auch bei Servern ohne einen solchen Listener funktioniert.

Die Lücke ist upstream bereits behoben, doch die Verfügbarkeit über Distributionspakete variiert. Ubuntu führt betroffene Kernel als verwundbar oder in Bearbeitung. The Hacker News berichtet, dass Fixes für RHEL 8, 9 und 10 sowie OpenShift 4 weiterhin aufgeschoben sind. Das SUSE-Advisory listet veröffentlichte Fixes für mehrere Enterprise-Produkte auf.

Was die Exploit-Behauptung belegt

In der Offenlegung vom 27. Oktober erklärte Anthropic, Claude habe den Linux-Exploit nach einer anfänglichen Aufforderung geschrieben. Laut Unternehmen könnte ein Angreifer Pakete an einen Server mit Multipath-TCP-Listener senden und ohne Zugangsdaten oder Benutzerinteraktion einen beliebigen Shell-Befehl als Root ausführen.

Multipath TCP, kurz MPTCP, erlaubt einer Verbindung, mehrere Netzwerkpfade zu nutzen. Linux-Anwendungen müssen dies laut The Hacker News beim Öffnen eines Sockets ausdrücklich anfordern. Der Zusammenhang zwischen MPTCP und diesem Exploit geht auf Anthropics Darstellung zurück. Der Kernel-Fix und die CVE-Beschreibung nennen MPTCP nicht als Voraussetzung für die zugrunde liegende Lücke.

Anthropic beschrieb zwei Ausnutzungsphasen. Zunächst veranlasst der Fehler den Kernel, zusätzliche Speicherinhalte zurückzugeben. Eine Antwort mit einem Kernel-Pointer verrät das Speicherlayout und hebelt so die Kernel Address Space Layout Randomization (KASLR) aus. In der zweiten Phase nutzt dieselbe Lücke einen Pufferüberlauf, um einen Callback-Pointer zu ersetzen und die Ausführung auf eine bereits im Kernelspeicher platzierte Nutzlast umzuleiten.

Das Unternehmen erklärte, ein misslungener Versuch scheitere nur am Verbindungsaufbau, sodass sich Versuche wiederholen ließen, ohne den Server zum Absturz zu bringen. Der Proof of Concept habe 48 Minuten gebraucht, um einen Kernel-Pointer auszulesen, und weitere fünf Minuten, um einen Shell-Befehl auszuführen. Der Beitrag enthält weder Exploit-Code noch die getestete Kernel-Version oder deren Konfiguration. Daher lassen sich nur begrenzte Schlüsse auf andere Installationen ziehen.

Ein Race während der Verbindungsbehandlung

Das Ubuntu-Advisory zu CVE-2026-98432 beschreibt einen Timing-Fehler: Eine CPU kann IPv4-Socket-Optionen freigeben, während eine andere sie während der TCP-Verbindungsbehandlung noch liest. Das Lesen des freigegebenen Speichers führt zu einer Use-After-Free-Situation. Ein verwandtes Problem tritt bei der Migration von Request-Sockets auf.

Der Fix verzögert das Freigeben der Optionen, bis parallele Leser fertig sind. IPv6 ist vom ersten Problem nicht betroffen, weil dessen Verbindungscode die Optionen kopiert. Das Advisory nennt separat ein IPv6-Migrationsproblem mit von CALIPSO gesetzten Optionen, das in einem anderen Patch behoben werden soll. IPv6 ist damit nicht pauschal von verwandten Problemen ausgenommen.

The Hacker News berichtet, dass die Lücke auf Linux 4.4 zurückgeht und Entwickler den Fix am 5. Oktober angewendet haben. Die CVE wurde am 15. Oktober veröffentlicht, also bevor Anthropic seine Exploit-Behauptung offenlegte.

Die Schweregradbewertungen weichen voneinander ab. Das CVE-Team des Kernels vergibt 9,8 von 10 und stuft die Angriffskomplexität als niedrig ein. Das Red-Hat-Advisory nennt einen vorläufigen Wert von 8,1 mit hoher Angriffskomplexität. Dieselbe Unterscheidung spiegelt sich in SUSEs Bewertung mit 8,1 wider. Red Hat beschreibt Systemabstürze als primäre Folge, daneben mögliche Speicherbeschädigung.

Welche Fixes verfügbar sind

Das Ubuntu-Advisory, zuletzt am 28. Oktober aktualisiert, führt seine Hauptkernel für 22.04 LTS, 24.04 LTS, 26.04 LTS und 26.10 als verwundbar mit laufenden Fixes auf. Seine Hauptkernel für 16.04, 18.04 und 20.04 sind ebenfalls verwundbar. Aufgeführte Cloud-, FIPS- und Echtzeit-Kernelvarianten haben eigene ausstehende Status. Die vorgeschlagenen Versionen mit der Markierung „work in progress“ sind keine veröffentlichten Fixes.

Die SUSE-Liste veröffentlichter Pakete nennt folgende Mindestversionen mit Fix für kernel-default:

  • SLES 15 SP4-LTSS und SUSE Linux Enterprise Micro 5.3 und 5.4: 5.14.21-150400.24.246.1.
  • SLES 15 SP5-LTSS und SUSE Linux Enterprise Micro 5.5: 5.14.21-150500.55.195.1.
  • SLES 15 SP6-LTSS: 6.4.0-150600.23.143.1.
  • SLES 16.0: 6.12.0-160000.40.1.

Für Echtzeit-Kernel listet SUSE gesondert kernel-rt-Fixes bei 5.14.21-150400.15.192.2 für Micro 5.4 und 5.14.21-150500.13.167.2 für Micro 5.5. Diese paketspezifischen Versionen sind relevant, auch wenn der Gesamtstatus der CVE bei SUSE weiterhin „Pending“ lautet.

Für andere Distributionen berichtet The Hacker News über Fixes in Debian trixie linux 6.12.113-1, Debian 12 linux 6.1.190-1 und linux-6.12 6.12.113-1~deb12u1. Außerdem nennt die Quelle die UEK-Advisories ELSA-2026-500397, ELSA-2026-500398 und ELSA-2026-500399 für Oracle Linux 7 bis 10. Für Amazon Linux 2023 nennt er Fixes für kernel6.18 bei 6.18.56-125.164.amzn2023 und kernel6.12 bei 6.12.113-138.209.amzn2023. Diese decken nicht jedes Amazon-Linux-Kernelpaket ab.

Red Hat erklärt, dass keine verfügbare Mitigation seine Kriterien für Einsatz, Anwendbarkeit und Stabilität erfüllt. Die Belege reichen nicht aus, um zu sagen, dass das Deaktivieren von MPTCP oder das Filtern von Verbindungsanfragen mit IP-Optionen die Lücke abmildern würde. Laut The Hacker News gab es am 29. Oktober in den Herstellerhinweisen, dem CVE-Eintrag oder dem Beitrag von Anthropic keine Berichte über Angriffe mit diesem Exploit. Das unterscheidet sich vom Proof of Concept, den das Unternehmen behauptet.

Sicherheitsdossiers

Auch interessant

Quellen

Zurück zur Startseite

Aktuelle Cybersecurity-News

Alle Cybersecurity-News →