Script de validation défensive CVE-2026-23111

Aperçu

CVE-2026-23111 est une vulnérabilité du noyau Linux dans nf_tables qui peut être exploitée pour une élévation de privilèges locale par un utilisateur non privilégié sur les systèmes où les espaces de noms utilisateur et nftables sont disponibles.[1][2] Les avis publics des fournisseurs et des gouvernements la décrivent comme un problème local affectant les distributions Linux et soulignent que le correctif est la solution principale.[3][4]

Ce dépôt contient un script de validation défensive conçu pour aider à évaluer si un hôte expose les conditions techniques associées à cette CVE sans fournir d'exploit d'élévation de privilèges. Il vérifie les conditions pertinentes du noyau et de l'exécution, charge optionnellement le module nf_tables pour des tests fonctionnels complets, tente un chemin de validation non privilégié contrôlé en utilisant unshare et nft, collecte des traces de diagnostic locales et classe l'hôte en verdicts opérationnels tels que probablement sûr, bloqué par la politique locale, ou chemin exposé disponible.[1][5]

Ce qu'est la CVE

Selon le NVD, CVE-2026-23111 est une vulnérabilité du noyau Linux dans nf_tables résolue comme un correctif de bogue logique dans netfilter et exploitable pour une élévation de privilèges locale à partir d'un utilisateur non privilégié via les espaces de noms utilisateur et nftables sur les configurations concernées.[1] L'avis de sécurité d'Ubuntu décrit le même chemin d'exploitation de haut niveau et suit les états des paquets affectés et corrigés par version.[2]

Red Hat déclare qu'un utilisateur local peu privilégié peut exploiter le problème pour provoquer un déni de service ou potentiellement obtenir une élévation de privilèges, et documente une voie d'atténuation basée sur l'empêchement du chargement du module nf_tables lorsque cela est acceptable d'un point de vue opérationnel.[3] Les directives nationales du Centre canadien pour la cybersécurité orientent également les organisations concernées vers les mises à jour des fournisseurs et mentionnent la régénération de l'initramfs lors de l'utilisation de mesures d'atténuation par blocage de module.[4]

Ce que fait le script

Le script est destiné à une évaluation défensive de l'exposition, et non à l'exploitation. Il est conçu pour :

• Identifier le noyau en cours d'exécution, la famille de distribution et les paramètres de durcissement d'exécution pertinents.
• Vérifier si CONFIG_USER_NS et CONFIG_NF_TABLES semblent présents.[1]
• Inspecter kernel.unprivileged_userns_clone et user.max_user_namespaces pour estimer si les espaces de noms utilisateur non privilégiés sont disponibles.
• Détecter si un refus dur de modprobe (install nf_tables /bin/false) ou une liste noire faible est en place pour le module nf_tables.
• Vérifier le changelog RPM du noyau du fournisseur pour une entrée de rétroportage de CVE-2026-23111 (famille RHEL uniquement).
• Empreinter /proc/kallsyms pour le symbole vulnérable (nft_map_catchall_activate) par rapport au symbole post-correctif (nft_catchall_set_activate) avant toute interaction avec le module.
• Optionnellement charger nf_tables via modprobe lorsque est spécifié (voir ci-dessous) et le décharger automatiquement à la sortie.

Le script stocke les journaux dans un sous-répertoire du répertoire du script et les supprime par défaut sauf si --keep-logs est utilisé.

Politique de chargement du module

Par défaut, le script ne charge jamais nf_tables. Si le module n'est pas déjà chargé au démarrage du script, tous les tests nft fonctionnels sont ignorés et le verdict est dérivé uniquement de la version du noyau, de l'empreinte kallsyms, de la configuration modprobe, du changelog RPM et des preuves de politique LSM/sysctl.

Cette valeur par défaut prudente évite d'étendre involontairement la surface d'attaque sur les hôtes de production. Pour activer des tests fonctionnels complets sur un système contrôlé ou instrumenté, utilisez --allow-load-module en tant que root (voir ci-dessous).

Utilisation

# Par défaut — pas de chargement de module, verdict basé uniquement sur les preuves de politique
./check_cve_2026_23111.sh
./check_cve_2026_23111.sh --color
./check_cve_2026_23111.sh --keep-logs
./check_cve_2026_23111.sh --color --keep-logs

# Test fonctionnel complet — charge (et décharge) nf_tables, nécessite root
sudo ./check_cve_2026_23111.sh --allow-load-module
sudo ./check_cve_2026_23111.sh --allow-load-module --color --keep-logs

Options

Quand utiliser --allow-load-module

Utilisez --allow-load-module lorsque vous avez besoin du verdict le plus fiable sur une machine virtuelle de test isolée, non productive ou spécialement construite. Scénarios typiques :

• Un noyau dans la plage vulnérable est en cours de validation avant le déploiement du correctif du fournisseur.
• Le système de test a KASAN ou une autre instrumentation activée et vous souhaitez observer les traces du noyau.
• Le module n'est pas utilisé sur l'hôte cible et une vérification complète de bout en bout du chemin est requise pour une preuve d'audit.

N'utilisez pas --allow-load-module sur des hôtes de production où nf_tables est intentionnellement bloqué ou où son chargement violerait une politique de durcissement.

Portes de sécurité pour --allow-load-module

Avant de tenter de charger le module, le script applique les vérifications suivantes et quitte avec une erreur si l'une d'elles échoue :

1. Un refus dur de modprobe (install nf_tables /bin/false) ne doit pas être présent dans /etc/modprobe.d/.
2. modprobe doit être disponible sur le système.
3. Le script doit être exécuté en tant que root (uid 0).

Si le module est chargé avec succès par le script, modprobe -r nf_tables est appelé à la sortie via le piège cleanup(), quelle que soit la façon dont le script se termine (succès, erreur ou CTRL+C).

Modèle de verdict

Le script utilise des verdicts opérationnels plutôt que des résultats d'exploitation :

Ces verdicts sont destinés à soutenir la priorisation des correctifs et le triage défensif, et non à remplacer la validation de l'état des paquets du fournisseur.

Couverture des versions du noyau

Le script mappe le noyau en cours d'exécution par rapport aux points de correction amont documentés :

Atténuation recommandée

L'action recommandée principale est d'installer la mise à jour du noyau corrigée par le fournisseur et de redémarrer sur le noyau corrigé.[2][3][4] Étant donné que l'exploitation dépend de la surface d'attaque locale du noyau, un durcissement supplémentaire peut réduire l'exposition pendant la planification ou la validation du correctif.[5][6]

Actions prioritaires

1. Corriger le noyau en utilisant l'avis officiel de la distribution et redémarrer sur la version corrigée.[2][3][4]
2. Restreindre les espaces de noms utilisateur non privilégiés lorsque les exigences métier le permettent, car le chemin d'attaque documenté dépend de leur disponibilité pour les utilisateurs non privilégiés.[1][5][6]
3. Désactiver ou bloquer le chargement de nf_tables si le système n'a pas besoin de la fonctionnalité nftables et que le changement a été validé pour l'impact opérationnel.[3][4]
4. Limiter les capacités réseau privilégiées telles que les chemins d'accès impliquant CAP_NET_ADMIN, et réduire le nombre de comptes pouvant manipuler l'état du pare-feu.[5]

Exemples d'étapes de durcissement

Restreindre les espaces de noms utilisateur non privilégiés :

echo 'kernel.unprivileged_userns_clone=0' > /etc/sysctl.d/99-cve-2026-23111.conf
echo 'user.max_user_namespaces=0' >> /etc/sysctl.d/99-cve-2026-23111.conf
sysctl --load /etc/sysctl.d/99-cve-2026-23111.conf

Bloquer le chargement du module nf_tables lorsque c'est opérationnellement sûr :

echo 'install nf_tables /bin/false' > /etc/modprobe.d/disable-nf_tables.conf
rmmod nf_tables 2>/dev/null || true

Si une atténuation par blocage de chargement de module est utilisée, certaines directives recommandent de régénérer l'initramfs afin que le module bloqué ne soit pas chargé lors du démarrage précoce.[4]

Remarque spécifique à Ubuntu

Ubuntu documente les restrictions basées sur AppArmor pour les espaces de noms utilisateur non privilégiés comme un moyen de réduire la surface d'attaque plutôt que comme un substitut complet aux correctifs du noyau.[6] Un hôte peut sembler moins exposé lors des tests d'exécution car le chemin d'attaque est bloqué localement, alors que la correction à long terme nécessite toujours l'installation du paquet du noyau corrigé par le fournisseur.[2][6] Le script valide l'efficacité des restrictions AppArmor en tentant une invocation réelle de unshare --user et en vérifiant si CAP_NET_ADMIN à l'intérieur d'un espace de noms utilisateur+réseau est fonctionnel.

Remarque spécifique à Red Hat

Red Hat liste explicitement l'empêchement du chargement du module nf_tables comme une atténuation pour CVE-2026-23111 lorsque ce changement est approprié pour l'environnement.[3] Le script détecte cette configuration via check_modprobe_deny() et fait la distinction entre un refus dur (install nf_tables /bin/false, qui bloque le chargement à la demande) et une liste noire faible (qui ne le fait pas). Sur les systèmes de la famille RHEL, le script inspecte également le changelog RPM du noyau en cours d'exécution pour une entrée de rétroportage de CVE-2026-23111, permettant un verdict confirmé par le fournisseur indépendamment du numéro de version amont.

Références officielles

• NVD : Détail CVE-2026-23111 [1]
• Sécurité Ubuntu : CVE-2026-23111 [2]
• Sécurité Red Hat : CVE-2026-23111 [3]
• Avis du Centre canadien pour la cybersécurité : AL26-011 [4]
• Aperçu de la restriction des espaces de noms utilisateur AppArmor d'Ubuntu : Comprendre la restriction des espaces de noms utilisateur AppArmor [6]

Portée et sécurité

Ce README et le script qui l'accompagne sont destinés à la validation défensive, à l'inventaire et à la planification des atténuations. Ils ne remplacent pas les directives du fournisseur, la vérification au niveau des paquets ou les processus standard de gestion des correctifs, et ne doivent pas être utilisés comme un substitut à l'application des correctifs officiels décrits dans les avis liés.[2][3][4]

📚 Dépôt de recherche en sécurité éducative

Un dépôt pour apprendre, tester et rechercher des concepts de cybersécurité dans des environnements contrôlés.

⚠️ Avertissement de sécurité et juridique

Objectif

Ce dépôt est destiné uniquement à la recherche en sécurité éducative et autorisée.

Il est conçu pour aider les utilisateurs à apprendre :

• Les vulnérabilités de sécurité
• Les concepts de bac à sable et d'isolation
• Les pratiques de codage sécurisé et défensif

Utilisation autorisée uniquement

Utilisez ce dépôt uniquement dans des environnements où vous avez l'autorisation, tels que :

• Laboratoires personnels ou machines virtuelles
• Conteneurs Docker ou environnements isolés
• Tests de pénétration autorisés
• Formation en cybersécurité ou recherche académique

Toute utilisation non autorisée ou illégale est strictement interdite.

Aucune responsabilité

L'auteur et les contributeurs ne sont pas responsables des dommages, utilisations abusives, problèmes juridiques ou pertes causés par ce projet.

En utilisant ce dépôt, vous acceptez que :

• Vous êtes responsable de vos propres actions
• Vous l'utiliserez de manière légale et éthique
• Le projet est fourni sans garantie

Utilisation éthique

Ce projet est destiné à :

• La recherche en sécurité défensive
• L'éducation à la cybersécurité
• La sensibilisation aux vulnérabilités
• La recherche sur les systèmes et logiciels sécurisés

Veuillez suivre les pratiques de divulgation responsable et vous conformer à toutes les lois applicables.

Contact

Pour une divulgation responsable ou une collaboration, contactez le mainteneur du dépôt via GitHub.