Quatre défaillances de sécurité dans le noyau Linux permettent de monter à root; correctifs déjà dans les branches

Un chercheur en sécurité a publié un code d'exploitation fonctionnel pour quatre défaillances de sécurité dans le noyau Linux qui permettent à un utilisateur local d'atteindre les privilèges root. Les quatre erreurs - avec les noms informels utilisés par l'auteur: DirtyAH6, TUNderflow, PPPoEject et DiagSpill- ont été signalés à l'équipe de sécurité du noyau à la mi-juillet et les correctifs correspondants ont été intégrés et publiés dans des versions stables du noyau dans les semaines suivantes. Le chercheur a publié son analyse technique et ses exploits le 18 septembre suivant une coordination avec les distributions afin de s'assurer que les arrangements étaient diffusés avant la divulgation publique.

Faits confirmés : l'explosion est accessible au public et les patchs existent déjà dans les branches stables du noyau. Exécutez un noyau mis à jour qui inclut toutes les corrections bloque ces routes d'attaque; les versions stables contenant l'ensemble complet des corrections sont indiquées dans les annonces du projet principal du noyau ( https: / / www.kernel /). L'auteur documente que son code d'exploitation est accordé pour la construction de noyau en béton, peut causer des blocages et a été développé pour l'analyse dans des systèmes isolés.

Techniquement, les quatre défaillances partagent une racine: ce sont des erreurs de sécurité dans la gestion de la mémoire au sein du sous-système réseau du noyau. Chaque vulnérabilité permet de corrompre les structures internes du noyau - c'est-à-dire d'écrire un tampon, de réutiliser la mémoire déjà libérée ou de causer des débordements par les compteurs - et ainsi de manipuler le flux d'exécution à l'échelle des privilèges. Concrètement : Dirty AH6 est un accès hors limites dans le code IPsec pour l'en-tête d'authentification IPv6 ; TUNderflow exploite une erreur de calcul des tailles sur les appareils virtuels TUN / TAP qui peuvent faire que les données finissent en dehors du tampon ; PPPo Eject est un uso-de-memoria-released (use-after-free) dans PPPoE; et DiagSpill copie une liste de paramètres au-delà de la taille réservée lorsqu'un compteur 16 bits déborde.

Qui cela affecte - t - il? Principalement pour les systèmes qui n'ont pas appliqué les mises à jour du noyau et aux scénarios où un attaquant a déjà un accès limité au système (par exemple, un compte utilisateur non privilégié sur un serveur multi-utilisateurs, un processus à l'intérieur d'un conteneur ou une session distante avec de faibles autorisations). Trois des vulnérabilités nécessitent des appels réseau pertinents pour être accessibles à partir d'un processus sans privilèges, et cela dépend souvent de la disponibilité duespaces de noms d'utilisateurPas de privilèges. Les espaces de noms d'utilisateur permettent aux utilisateurs non privilégiés d'obtenir une racine d'ID dans un espace de noms isolé; de nombreuses distributions les permettent par défaut et cela facilite la manipulation des fonctions réseau nécessaires à certains des exploits. DiagSpill est l'exception : il ne nécessite pas d'espaces de noms d'utilisateur, mais il nécessite la présence du module réseau SCTP activé dans le système.

Conséquences pratiques: si un attaquant local profite de l'un de ces échecs, il peut obtenir un shell avec des privilèges racine et, par conséquent, le contrôle complet du système. Cela rend l'accès limité à un contrôle complet, avec l'impact évident sur la confidentialité, l'intégrité et la disponibilité. Bien que l'auteur affirme ne pas avoir observé l'utilisation dans des attaques réelles avant publication, la disponibilité publique de l'explosion accroît le risque dans des systèmes partagés ou périmés. Il convient également de noter que l'explosion publique peut produire des blocs et s'adapter à des bâtiments spécifiques; extraire une chaîne d'exploitation fiable contre un système arbitraire peut nécessiter plus de travail (par exemple, "moudre" la mémoire de la cible), mais il n'est pas impossible dans des environnements favorables.

Information estimée et zones incertaines: le chercheur documente que certaines routes éloignées sont théoriques ou extrêmement difficiles. Par exemple, DirtyAH6 pourrait causer un verrouillage à distance dans les hôtes qui agissent comme routeurs IPv6 avec IPsec en mode de transport et, avec des techniques avancées de moulage de la mémoire, dans son laboratoire n'a atteint des privilèges à distance que dans des conditions contrôlées. Pour DiagSpill l'auteur indique qu'il n'a pas vu une façon pratique de distant la racine même avec un moulage parfait de la mémoire. Ces points sont marqués comme suit: estimations basées sur des essais en laboratoire, pas comme confirmation d'exploitation à distance sur le terrain.

Ce qu'un administrateur ou un utilisateur devrait faire maintenant. Le grattage est la mesure principale et recommandée: mettre à jour le noyau vers une version qui inclut toutes les corrections publiées par le projet du noyau ou, mieux encore, appliquer les paquets de sécurité fournis par sa distribution. Vérifiez l'avis de sécurité de votre distribution (Debian, Ubuntu, Red Hat, SUSE, etc.) parce que ces organisations intègrent les correctifs dans leurs propres numéros de version et les horaires de publication; assurez-vous que la mise à jour distribuée contient les corrections complètes, non seulement correspond aux numéros de branche principale.

Si vous ne pouvez pas vous garer immédiatement, il y a une atténuation temporaire qui réduit le risque : désactiver les utilisateurs d'espaces de noms sans privilèges et / ou interdire les modules et les caractéristiques du réseau concerné. Pour les espaces de noms d'utilisateurs, une action pratique (vérifier la syntaxe dans votre système et votre distribution) est de les désactiver avec sysctl, par exemple: sysctl -w noyau. Non privilégié _ utilisateurs _ clone = 0 ou persistent dans / etc / sysctl.conf. Ceci ferme l'accès non privilégié à DirtyAH6, TUNderflow et PPPoEject, mais C'est pas vrai. protège contre DiagSpill et n'aide pas les processus qui ont déjà des privilèges réseau (p. ex. conteneurs privilégiés).

Une autre atténuation temporaire consiste à empêcher le chargement ou l'utilisation de modules connexes : si vous n'avez pas besoin de AH / IPv6, TUN / TAP, PPPoE ou SCTP, retirez ou bloquez-les (par exemple avec modprobe -r ou ajoutez-les à / etc / modprobe.d / blacklist). Cependant, les voies d'accès au noyau peuvent être multiples, et le chercheur lui-même recommande de se garer au lieu de ne compter que sur des caractéristiques invalidantes, car d'autres surfaces peuvent exposer les mêmes défaillances.

Parallèlement aux correctifs et aux mesures d'atténuation, vérifiez les enregistrements et les configurations : vérifiez l'accès local récent, l'utilisation de conteneurs exposés et de services réseau qui pourraient permettre à un utilisateur non privilégié d'interagir avec les routines en cause. Pour mieux comprendre la relation entre les espaces de noms d'utilisateurs et les privilèges, la documentation officielle du noyau fournit un contexte pour leur comportement et configuration: https: / / www.kernel / doc / html / latest / admin-guide / user-namspaces.html.

Contexte et tendances: l'auteur indique qu'il a identifié ces défaillances à l'aide d'une méthodologie assistée par des outils d'intelligence artificielle qui ont cartographié comment le noyau gère la mémoire et raisonné sur sa disposition en temps d'exécution; l'intervention des aides «AI» est déjà attribuée dans les engagements de correction. Ce cas fait partie d'une série récente d'étapes de privilèges Linux détectées avec le soutien de modèles et d'outils d'analyse avancés. Ce développement technique ne modifie pas la contre-mesure pratique : le maintien des correctifs appliqués et la réduction de la surface exposée restent la défense la plus fiable.

Résumé final : mettre à jour votre noyau vers la version corrigée distribuée par sa distribution dès que possible. Si vous ne pouvez pas mettre à jour immédiatement, désactiver les espaces de noms sans privilèges et, si possible, empêcher l'utilisation des modules réseau affectés. Vérifiez les sorties de sécurité de votre fournisseur de distribution, planifiez le redémarrage contrôlé et traitez ces exploits publics comme une menace réelle pour les systèmes et conteneurs multi-utilisateurs jusqu'à ce que les correctifs soient installés.