Description succincte :

SCTPhantom est un use-after-free dans le sous-système SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) du noyau Linux, permettant à un utilisateur local non privilégié d'obtenir les droits de superutilisateur (root).

La cause racine est une divergence d'identités lors du traitement du chunk ASCONF : la vérification de l'opération DEL-IP est effectuée contre l'adresse source du paquet IPv4 (S), tandis que le traitement ultérieur utilise le transport sélectionné via l'Address Parameter (L). De ce fait, la séquence ordonnée

passe la vérification et supprime transport(L), après quoi l'opération wildcard DEL-IP 0.0.0.0 réutilise le pointeur déjà libéré comme « chemin conservé ». En conséquence, asoc->peer.primary_path et asoc->peer.active_path restent des pointeurs pendants vers le struct sctp_transport libéré, et l'appel suivant à getsockopt(SCTP_STATUS) les déréférence.

La logique vulnérable a été introduite dans Linux 2.6.25 (année 2007, commit 42e30bf3463c), soit environ 18 ans de présence dans le noyau.

Attaque :

• ne nécessite pas d'accès distant - seulement un compte local non privilégié
• ne nécessite pas CAP_NET_ADMIN ni CAP_SYS_ADMIN, fonctionne lorsque le profil seccomp par défaut est actif ; ASCONF et AUTH sont activés par socket via SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, il n'est donc pas nécessaire de modifier le sysctl net.sctp.addip_enable
• constitue une primitive fonctionnelle d'évasion de conteneur vers l'hôte : les auteurs ont obtenu un root hôte dans 6 essais sur 8, l'étape finale étant call_usermodehelper_exec(), qui lance un processus dans les initial namespaces de l'hôte
• en cas d'échec de l'exploitation, elle se termine « proprement », sans kernel panic, ce qui complique la détection
• la chaîne d'exploitation réutilise le code noyau existant (commit_creds() orienté données), sans shellcode ni ROP classique

Technologies concernées :

• Noyau Linux, sous-système net/sctp (module sctp), traitement d'ASCONF dans net/sctp/sm_make_chunk.c
• Module sctp_diag (dépend de sctp), utilisé pour l'inspection des sockets SCTP

La vulnérabilité n'est exploitable que si SCTP est disponible : si le module sctp n'est pas chargé et que son chargement automatique est bloqué, le vecteur n'est pas accessible.

Cibles confirmées par les auteurs (root obtenu) :

Versions de noyau corrigées :

Les noyaux des fournisseurs peuvent contenir un backport du correctif avec une version plus ancienne dans la chaîne de version - la version du noyau elle-même n'est pas un indicateur suffisant de vulnérabilité, fiez-vous à l'advisory ou aux sources du fournisseur.

Vecteur d'attaque et niveau de gravité selon CVSS v4.0 :

Score de base : 8.5 (HIGH)

Vecteur : 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

Ce que fait ce correctif

Le DaemonSet, automatiquement sur chaque nœud worker du cluster :

1. Vérifie l'état des modules - regarde si sctp et sctp_diag sont chargés, et avec quel refcnt. La vérification est volontairement passive : le DaemonSet n'ouvre pas de socket SCTP avant la mise en place de la blacklist, afin de ne pas déclencher le chargement automatique du module sur un nœud où il n'est pas encore chargé
2. Vérifie si SCTP est utilisé sur le nœud - analyse le refcnt du module et les entrées vivantes dans /proc/net/sctp/assocs et /proc/net/sctp/eps. Kubernetes lui-même n'utilise pas SCTP, mais une charge de travail utilisateur peut déclarer protocol: SCTP dans des Service/Pod
3. Bloque les modules vulnérables - crée /etc/modprobe.d/blacklist-sctp.conf avec les règles install et blacklist pour sctp et sctp_diag
4. Décharge les modules - exécute rmmod pour sctp_diag, puis sctp (l'ordre est important : sctp_diag dépend de sctp). Si des connexions SCTP vivantes sont détectées, le déchargement est ignoré, sauf si FORCE_APPLY=true est explicitement défini
5. Vérifie l'atténuation - contrôle que la configuration est présente, que modprobe sctp est rejeté, et que la création d'une socket SCTP (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) n'aboutit plus
6. Surveille l'état - vérifie toutes les heures la présence de la configuration, la restaure si elle disparaît et décharge à nouveau les modules s'ils se retrouvent chargés

Important : deux issues possibles sur un nœud

L'atténuation se compose de deux parties indépendantes, et sur certains nœuds, seule l'une d'elles est appliquée.

1. Blacklist (toujours appliquée, fiable). Après la création de /etc/modprobe.d/blacklist-sctp.conf, le module sctp ne peut plus être chargé - ni automatiquement lors d'un socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP), ni par un modprobe explicite. Cela ferme le vecteur sur les nœuds où le module n'était pas encore chargé (état typique : SCTP n'est pas utilisé par Kubernetes et n'est chargé qu'à la demande).

2. Déchargement du module de la mémoire (pas toujours possible). Si sctp est déjà chargé, le décharger ne sera généralement pas possible. Sur les nœuds testés de Yandex Managed Kubernetes (Ubuntu 22.04, noyau 5.15.0-181-generic), un module sctp fraîchement chargé et utilisé par personne a déjà refcnt=6 avec une liste de holders vide et des /proc/net/sctp/{assocs,eps} vides, et rmmod renvoie ERROR: Module sctp is in use. Le compteur ne diminue pas avec le temps.

D'où deux conséquences :

• refcnt n'est pas un indicateur d'utilisation de SCTP - le DaemonSet ne l'affiche qu'à titre informatif et prend la décision de déchargement en fonction des entrées vivantes dans /proc/net/sctp/assocs et /proc/net/sctp/eps
• sur un nœud où sctp est déjà résident, le DaemonSet signale honnêtement ⚠ mitigation applied PARTIALLY. La blacklist y est déjà en place (après un redémarrage, le module ne reviendra pas), mais jusqu'au redémarrage, le nœud reste vulnérable. Pour fermer complètement le vecteur, ces nœuds doivent être redémarrés ou le groupe de nœuds doit être recréé

Pour trouver ces nœuds après le déploiement :

Compatibilité avec les charges de travail

Important : l'atténuation désactive complètement SCTP sur le nœud.

Kubernetes et les plugins réseau (Cilium, Calico) n'utilisent pas SCTP pour leur propre fonctionnement, l'atténuation est donc sûre pour la grande majorité des clusters. Cependant, si le cluster contient une charge de travail utilisant SCTP (par exemple, des applications télécom, de la VoIP/signalisation SS7/Diameter, un Service ou une NetworkPolicy avec protocol: SCTP), son trafic cessera de fonctionner.

Pour vérifier si de tels objets existent dans le cluster, avant le déploiement :

Si SCTP est utilisé sur le nœud, le DaemonSet ne décharge pas le module de la mémoire par défaut, il se contente de poser la blacklist (le module ne reviendra pas après un redémarrage du nœud) et écrit un avertissement dans les journaux. Pour forcer le déchargement en interrompant les connexions SCTP existantes, définissez dans le manifeste :

Démarrage rapide

1. Télécharger le DaemonSet

Ou cloner le dépôt :

2. Appliquer le correctif

3. Vérifier le statut d'application

4. Consulter les journaux d'application du correctif

5. Trouver les nœuds où l'atténuation n'a pas été entièrement appliquée

Exemple d'application réussie

Exemple d'application partielle (module déjà chargé)

Un tel nœud doit être redémarré : la blacklist empêchera le module de se recharger.

Vérification de l'efficacité de l'atténuation depuis un pod

La vérification la plus parlante consiste à reproduire la position de l'attaquant : un pod non privilégié avec les capabilities supprimées, comme dans la chaîne d'évasion de conteneur.

Sortie attendue sur un nœud protégé :

Sur un nœud non protégé, la sortie sera SCTP REACHABLE -> EXPLOITABLE, et la vérification elle-même déclenchera le chargement automatique du module sctp sur ce nœud (après quoi il ne sera probablement plus possible de le décharger - voir la section ci-dessus). Ne l'exécutez pas sur des nœuds non protégés sans nécessité.

Vérification manuelle de la vulnérabilité

Vous pouvez vérifier l'état du nœud manuellement. Connectez-vous au nœud en SSH et exécutez :

Attention : lancer cette vérification sur un nœud où le module n'est pas encore chargé déclenchera lui-même son chargement automatique. Ne l'exécutez qu'après avoir appliqué l'atténuation, ou en connaissance de cause.

Vérifier la configuration :

Vérifier que les modules vulnérables ne sont pas chargés :

Application hors Kubernetes

Si vous devez appliquer l'atténuation sur des hôtes classiques, en une seule ligne :

Suppression du correctif

Si vous devez supprimer le DaemonSet :

Important : la suppression du DaemonSet ne supprimera pas les fichiers de configuration des nœuds. Le fichier /etc/modprobe.d/blacklist-sctp.conf restera en place et continuera à protéger le système.

Pour supprimer complètement le correctif des nœuds, vous devez vous connecter à chaque nœud en SSH et supprimer manuellement le fichier :

Détails techniques

Autorisations utilisées :

• hostPID: true - pour accéder aux processus de l'hôte via nsenter
• privileged: true - pour écrire dans /etc et décharger les modules du noyau
• Volume mount / - pour accéder au système de fichiers de l'hôte

Image : ubuntu:22.04

Ressources :

• 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

Pourquoi install et blacklist dans la configuration : blacklist bloque le chargement par alias (y compris le chargement automatique lors d'un socket(..., IPPROTO_SCTP)), mais n'empêche pas un modprobe sctp explicite. La ligne install sctp /bin/false ferme également cette voie.

Pourquoi l'atténuation ne remplace pas la mise à jour du noyau : le blocage du module élimine le vecteur, mais le bug lui-même reste dans le noyau. La solution permanente est de mettre à jour le noyau vers une version corrigée (voir le tableau ci-dessus) ou de mettre à jour les images des nœuds et de recréer le groupe de nœuds.

Compatibilité

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

Licence

Apache License 2.0

Voir LICENSE pour plus de détails.

Support

En cas de problème, créez une issue dans le dépôt.