10
Il y a quelques jours, on a appris que Deux vulnérabilités ont été identifiées dans le noyau Linux le premier d'entre eux déjà catalogué comme CVE-2022-0435 et a été trouvé dans le module du noyau Linux qui assure le fonctionnement du protocole réseau TIPC (Transparent Inter-Process Communication).
Cette vulnérabilité pourrait permettre au code de s'exécuter au niveau du noyau en envoyant un paquet à un réseau spécialement conçu.
Le problème n'affecte que les systèmes avec le module de noyau tipc.ko chargé et configuré avec la pile TIPC, qui est généralement utilisée dans les clusters et n'est pas activée par défaut sur les distributions Linux non spécialisées.
Vulnérabilité il est causé par un débordement de pile qui se produit lors du traitement des paquets, la valeur du champ avec le nombre de nœuds membres du domaine dans lequel il dépasse 64.
Pour stocker les paramètres des nœuds dans le module tipc.ko, un tableau définit "u32 members[64 ]", mais en train de traiter ce qui est spécifié dans le package. Le numéro de nœud ne vérifie pas la valeur "member_cnt", ce qui permet d'utiliser des valeurs supérieures à 64 pour l'écrasement contrôlé des données dans la zone mémoire ci-dessous. la pile après la structure "dom_bef".
Le protocole TIPC a été développé à l'origine par Ericsson, il est conçu pour organiser la communication entre les processus d'un cluster et est activé principalement sur les nœuds du cluster. TIPC peut fonctionner sur Ethernet et UDP (port réseau 6118).
Lorsque vous travaillez sur Ethernet, une attaque peut être effectuée à partir du réseau local et, lors de l'utilisation d'UDP, à partir du réseau mondial, si le port n'est pas couvert par un pare-feu. L'attaque peut également être effectuée par un utilisateur local sans privilèges sur l'hôte. Pour activer TIPC, vous devez charger le module de noyau tipc.ko et configurer la liaison à une interface réseau à l'aide de netlink ou de l'utilitaire tipc.
Il est mentionné que lors de la construction du noyau en mode "CONFIG_FORTIFY_SRC=y" (utilisé dans RHEL), qui ajoute des contrôles de limites supplémentaires à la fonction memcpy(), le fonctionnement est limité à un arrêt d'urgence (le noyau passe à l'état "Kernel Panic").
S'il est exécuté sans vérifications supplémentaires et que des informations sur les indicateurs canary utilisés pour protéger la pile sont divulguées, le problème peut être utilisé pour exécuter du code à distance avec les droits du noyau. Les chercheurs qui ont identifié le problème disent que la technique d'exploitation est triviale et sera révélée après la suppression généralisée de la vulnérabilité dans les distributions.
Le bogue qui a généré la vulnérabilité a été introduit le 15 juin 2016 et est devenu une partie du noyau Linux 4.8. vulnérabilité corrigé dans les versions du noyau Linux 5.16.9, 5.15.23, 5.10.100, 5.4.179, 4.19.229, 4.14.266 et 4.9.301.
Une autre vulnérabilité qui a été trouvé dans le noyau Linux est CVE-2022-24122 dans le code pour gérer les contraintes rlimit dans différents espaces de noms d'utilisateurs.
Le bogue a été introduit dans une modification ajoutée à l'été 2021, déplaçant l'implémentation de certains compteurs RLIMIT pour utiliser la structure "ucounts". Les objets "ucounts" créés pour RLIMIT ont continué à être utilisés après avoir libéré la mémoire qui leur était allouée (use-after-free) en supprimant l'espace de noms qui leur était associé, ce qui a permis d'obtenir une exécution au niveau du noyau de leur code.
L'exploitation de la vulnérabilité par un utilisateur non privilégié n'est possible que si le système dispose d'un accès non privilégié à l'espace de noms d'identifiant d'utilisateur (espace de noms d'utilisateur non privilégié), qui est activé par défaut dans Ubuntu et Fedora, mais pas activé sur Debian et RHEL.
Pour contourner la vulnérabilité, vous pouvez désactiver l'accès sans privilège à l'espace de noms de l'utilisateur :
sysctl -w kernel.unprivileged_userns_clone=0
Le problème existe depuis le noyau Linux 5.14 et sera corrigé dans les mises à jour 5.16.5 et 5.15.19. Les branches stables de Debian, Ubuntu, SUSE/openSUSE et RHEL ne sont pas concernées par le problème, mais apparaissent dans les nouveaux noyaux Fedora et Arch Linux.