Kurzbeschreibung:

SCTPhantom ist ein Use-after-Free in dem Linux-Kernel-Subsystem SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061), das einem unprivilegierten lokalen Benutzer ermöglicht, Superuser-Rechte (root) zu erlangen.

Die Grundursache ist ein Identitätskonflikt bei der Verarbeitung des ASCONF-Chunks: Die Prüfung der DEL-IP-Operation erfolgt gegen die Quelladresse des IPv4-Pakets (S), während die weitere Verarbeitung den über den Address Parameter (L) gewählten transport verwendet. Dadurch passiert die geordnete Sequenz

die Prüfung und löscht transport(L), woraufhin die Wildcard-Operation DEL-IP 0.0.0.0 den bereits freigegebenen Zeiger als „gespeicherten Pfad" wiederverwendet. Infolgedessen bleiben asoc->peer.primary_path und asoc->peer.active_path hängende Zeiger auf den freigegebenen struct sctp_transport, und ein anschließender Aufruf von getsockopt(SCTP_STATUS) dereferenziert sie.

Die anfällige Logik wurde in Linux 2.6.25 eingeführt (2007, Commit 42e30bf3463c), ist also seit etwa 18 Jahren im Kernel vorhanden.

Angriff:

• erfordert keinen Fernzugriff – nur ein unprivilegiertes lokales Konto
• erfordert nicht CAP_NET_ADMIN und CAP_SYS_ADMIN, funktioniert mit aktivem Standard-Seccomp-Profil; ASCONF und AUTH werden pro Socket über SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED aktiviert, daher muss der Sysctl net.sctp.addip_enable nicht geändert werden
• ist ein funktionierendes Container-Escape-Primitive: Die Autoren erlangten in 6 von 8 Versuchen Host-Root; der letzte Schritt ist call_usermodehelper_exec(), das einen Prozess in den initialen Namespaces des Hosts startet
• endet bei fehlgeschlagener Ausnutzung „sauber", ohne kernel panic, was die Erkennung erschwert
• die Exploit-Kette verwendet vorhandenen Kernel-Code wieder (datenorientiertes commit_creds()), ohne Shellcode und klassisches ROP

Betroffene Technologien:

• Linux-Kernel, Subsystem net/sctp (Modul sctp), Verarbeitung von ASCONF in net/sctp/sm_make_chunk.c
• Modul sctp_diag (hängt von sctp ab), wird zur Inspektion von SCTP-Sockets verwendet

Die Schwachstelle ist nur ausnutzbar, wenn SCTP verfügbar ist: Wenn das Modul sctp nicht geladen und dessen Autoload blockiert ist, ist der Vektor nicht verfügbar.

Von den Autoren bestätigte Ziele (Root erlangt):

Korrigierte Kernel-Versionen:

Vendor-Kernel können einen Backport des Fixes bei einer älteren Versionsnummer enthalten – die Kernel-Version allein ist kein hinreichendes Indiz für die Schwachstelle; orientieren Sie sich an den Advisories oder den Quellen des Vendors.

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

Basisscore: 8.5 (HIGH)

Vektor: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Was dieser Fix bewirkt

Der DaemonSet führt auf jedem Worker-Knoten des Clusters automatisch Folgendes aus:

1. Prüft den Status der Module – prüft, ob sctp und sctp_diag geladen sind und mit welchem refcnt. Die Prüfung ist bewusst passiv: Der DaemonSet öffnet keinen SCTP-Socket, bevor die Blacklist eingerichtet ist, um das Laden des Moduls auf einem Knoten, auf dem es noch nicht geladen ist, nicht auszulösen.
2. Prüft, ob SCTP auf dem Knoten verwendet wird – analysiert den refcnt des Moduls und die aktiven Einträge in /proc/net/sctp/assocs und /proc/net/sctp/eps. Kubernetes selbst nutzt SCTP nicht, aber eine benutzerdefinierte Workload kann protocol: SCTP in Service/Pod deklarieren.
3. Blockiert die verwundbaren Module – erstellt /etc/modprobe.d/blacklist-sctp.conf mit install- und blacklist-Regeln für sctp und sctp_diag.
4. Entlädt die Module – führt rmmod für sctp_diag und dann für sctp aus (die Reihenfolge ist wichtig: sctp_diag hängt von sctp ab). Wenn aktive SCTP-Verbindungen erkannt werden, wird das Entladen übersprungen, sofern nicht explizit FORCE_APPLY=true gesetzt ist.
5. Verifiziert die Mitigation – prüft, ob die Konfiguration vorhanden ist, ob modprobe sctp abgelehnt wird und ob das Erstellen eines SCTP-Sockets (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) nicht mehr möglich ist.
6. Überwacht den Zustand – prüft stündlich das Vorhandensein der Konfiguration, stellt sie bei Verlust wieder her und entlädt die Module erneut, falls sie wieder geladen wurden.

Wichtig: zwei mögliche Ausgänge auf dem Knoten

Die Mitigation besteht aus zwei unabhängigen Teilen, und auf einigen Knoten wird nur einer von ihnen angewendet.

1. Blacklist (wird immer zuverlässig angewendet). Nach der Erstellung von /etc/modprobe.d/blacklist-sctp.conf kann das Modul sctp nicht mehr geladen werden – weder automatisch bei socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP) noch durch explizites modprobe. Dies schließt den Vektor auf Knoten, auf denen das Modul noch nicht geladen war (typischer Zustand: SCTP wird von Kubernetes nicht verwendet und nur bei Bedarf geladen).

2. Entladen des Moduls aus dem Speicher (nicht immer möglich). Wenn sctp bereits geladen ist, lässt es sich meist nicht entladen. Auf getesteten Yandex Managed Kubernetes-Knoten (Ubuntu 22.04, Kernel 5.15.0-181-generic) hat ein frisch geladenes und von niemandem verwendetes Modul sctp bereits refcnt=6 bei leerer Holder-Liste und leeren /proc/net/sctp/{assocs,eps}, und rmmod gibt ERROR: Module sctp is in use zurück. Der Zähler nimmt mit der Zeit nicht ab.

Daraus ergeben sich zwei Konsequenzen:

• refcnt ist kein Indikator für die SCTP-Nutzung – der DaemonSet gibt ihn nur informativ aus und entscheidet über das Entladen anhand der aktiven Einträge in /proc/net/sctp/assocs und /proc/net/sctp/eps.
• Auf einem Knoten, auf dem sctp bereits resident ist, meldet der DaemonSet ehrlich ⚠ mitigation applied PARTIALLY. Die Blacklist ist dort bereits aktiv (nach einem Neustart wird das Modul nicht zurückkehren), aber bis zum Neustart bleibt der Knoten verwundbar. Um den Vektor vollständig zu schließen, müssen solche Knoten neu gestartet oder die Node-Gruppe neu erstellt werden.

Solche Knoten nach dem Rollout finden:

Kompatibilität mit Workloads

Wichtig: Die Mitigation deaktiviert SCTP auf dem Knoten vollständig.

Kubernetes und Netzwerk-Plugins (Cilium, Calico) verwenden SCTP nicht für den eigenen Betrieb, daher ist die Mitigation für die allermeisten Cluster unbedenklich. Wenn es jedoch im Cluster eine Workload gibt, die SCTP verwendet (z.B. Telekom-Anwendungen, VoIP/Signalisierung SS7/Diameter, Service oder NetworkPolicy mit protocol: SCTP), wird deren Datenverkehr nicht mehr funktionieren.

Prüfen, ob solche Objekte im Cluster vorhanden sind, bevor Sie den Rollout durchführen:

Wenn SCTP auf dem Knoten verwendet wird, entlädt der DaemonSet das Modul standardmäßig nicht aus dem Speicher, sondern setzt nur die Blacklist (das Modul kehrt nach einem Neustart des Knotens nicht zurück) und schreibt eine Warnung in die Logs. Um das Entladen zu erzwingen und vorhandene SCTP-Verbindungen abzubrechen, setzen Sie im Manifest:

Schnellstart

1. DaemonSet herunterladen

Oder das Repository klonen:

2. Fix anwenden

3. Status der Anwendung prüfen

4. Logs der Fix-Anwendung anzeigen

5. Knoten finden, auf denen die Mitigation nicht vollständig angewendet wurde

Beispiel einer erfolgreichen Anwendung

Beispiel einer teilweisen Anwendung (Modul war bereits geladen)

Ein solcher Knoten muss neu gestartet werden: Die Blacklist verhindert bereits, dass das Modul erneut geladen wird.

Überprüfung der Wirksamkeit der Mitigation aus einem Pod

Der aussagekräftigste Test ist, die Position des Angreifers zu reproduzieren: ein unprivilegierter Pod mit entfernten Capabilities, wie in der Container-Escape-Kette.

Erwartete Ausgabe auf einem geschützten Knoten:

Auf einem ungeschützten Knoten lautet die Ausgabe SCTP REACHABLE -> EXPLOITABLE, und der Test selbst führt dazu, dass das Modul sctp auf diesem Knoten automatisch geladen wird (danach lässt es sich wahrscheinlich nicht mehr entladen – siehe Abschnitt oben). Führen Sie ihn nicht ohne Notwendigkeit auf ungeschützten Knoten aus.

Manuelle Überprüfung der Schwachstelle

Sie können den Zustand des Knotens manuell überprüfen. Stellen Sie per SSH eine Verbindung zum Knoten her und führen Sie Folgendes aus:

Achtung: Das Ausführen dieser Prüfung auf einem Knoten, auf dem das Modul noch nicht geladen ist, führt selbst zu dessen Autoload. Führen Sie sie nur nach der Anwendung der Mitigation oder bewusst durch.

Konfiguration prüfen:

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

Anwendung außerhalb von Kubernetes

Wenn Sie die Mitigation auf normalen Hosts anwenden möchten, hier ein Einzeiler:

Entfernen des Fixes

Falls das DaemonSet entfernt werden muss:

Wichtig: Das Löschen des DaemonSet entfernt nicht die Konfigurationsdateien von den Knoten. Die Datei /etc/modprobe.d/blacklist-sctp.conf bleibt bestehen und schützt das System weiterhin.

Um den Fix vollständig von den Knoten zu entfernen, müssen Sie sich per SSH mit jedem Knoten verbinden und die Datei manuell löschen:

Technische Details

Verwendete Berechtigungen:

• hostPID: true – für den Zugriff auf die Host-Prozesse über nsenter
• privileged: true – zum Schreiben nach /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

Warum in der Konfiguration sowohl install als auch blacklist: blacklist blockiert das Laden über den Alias (einschließlich des Autoloads bei socket(..., IPPROTO_SCTP)), verhindert aber nicht das explizite modprobe sctp. Die Zeile install sctp /bin/false schließt auch diesen Weg.

Warum die Mitigation kein Ersatz für ein Kernel-Update ist: Das Blockieren des Moduls beseitigt den Vektor, aber der Fehler selbst bleibt im Kernel. Die dauerhafte Lösung ist ein Update des Kernels auf eine korrigierte Version (siehe Tabelle oben) oder das Aktualisieren der Node-Images und das Neuerstellen der Node-Gruppe.

Kompatibilität

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

Lizenz

Apache License 2.0

Siehe LICENSE für Details.

Unterstützung

Bei Problemen erstellen Sie bitte ein Issue im Repository.