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 --allow-load-module est spécifié (voir ci-dessous) et le décharger automatiquement à la sortie.
• Exécuter une étape de validation contrainte avec unshare -U -n --map-root-user + nft lorsque le module est chargé, et enregistrer stdout, stderr et les journaux récents du noyau.
• Vérifier que unshare --user crée effectivement un espace de noms et que CAP_NET_ADMIN est fonctionnel à l'intérieur, pour confirmer si les restrictions AppArmor ou SELinux sont réellement efficaces.
• Mettre en évidence si les contrôles de sécurité locaux tels qu'AppArmor ou SELinux semblent bloquer le chemin testé.[6]
• Émettre une sortie orientée verdict avec une mise en évidence colorée optionnelle pour faciliter le triage.

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

Option	Description
--allow-load-module	Autorise le script à charger nf_tables via modprobe si le module n'est pas déjà chargé. Active l'exercice complet du chemin catchall nft et le test d'efficacité de CAP_NET_ADMIN. Le module est déchargé automatiquement à la sortie. Nécessite root. Refusé si un refus dur de modprobe est déjà en place. À utiliser uniquement sur des systèmes non productifs ou instrumentés.
--color	Active la sortie colorée sur stdout lorsque le terminal le supporte.
--keep-logs	Conserve les journaux et les traces dans le répertoire du script au lieu de les supprimer à la sortie.
--help	Affiche les informations d'utilisation et quitte.

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 :