Récemment Chercheurs sécurité Qualys (une société de sécurité cloud, de conformité et de services associés) publié les détails d'une vulnérabilité ce qu'ils ont détecté et ce ils affectent le noyau Linux.
CVE-2021-33909 affecte le noyau et permet à un utilisateur local d'exécuter du code et élever les privilèges en manipulant des répertoires hautement imbriqués.
La vulnérabilité est due au manque de validation du résultat de la conversion de size_t en type int avant d'effectuer des opérations sur le code seq_file, qui crée des fichiers à partir d'une séquence d'enregistrements. Le manque de validation peut entraîner des écritures dans une zone en dehors des limites de la mémoire tampon lors de la création, du montage et de la suppression d'une structure de répertoires avec un niveau d'imbrication très élevé (taille de chemin supérieure à 1 Go).
Tout utilisateur non privilégié peut obtenir des privilèges root sur un hôte vulnérable en exploitant cette vulnérabilité dans une configuration par défaut.
En conséquence, un attaquant peut obtenir une chaîne de 10 octets "// supprimé" avec un décalage de "- 2 Go - 10 octets", pointant vers la zone immédiatement avant le tampon alloué.
La menace de vulnérabilité est aggravée par le fait que les chercheurs ont pu préparer des exploits fonctionnels sur Ubuntu 20.04, Debian 11 et Fedora 34 dans les paramètres par défaut. Il est à noter que d'autres distributions n'ont pas été testées, mais théoriquement elles sont également sensibles au problème et peuvent être attaquées.
L'exploitation réussie de cette vulnérabilité permet à tout utilisateur non privilégié d'obtenir des privilèges root sur l'hôte vulnérable. Les chercheurs en sécurité de Qualys ont pu vérifier indépendamment la vulnérabilité, développer un exploit et obtenir les privilèges root complets sur les installations par défaut d'Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11 et Fedora 34 Workstation. D'autres distributions Linux sont susceptibles d'être vulnérables et probablement exploitables.
Le travail de l'exploit se résume à créer une hiérarchie d'environ un million de répertoires imbriqué via l'appel mkdir() pour atteindre une taille de chemin de fichier supérieure à 1 Go.
Ce répertoire est monté par montage dans un espace de noms d'utilisateur séparé, après quoi la fonction rmdir () est exécutée pour le supprimer. En parallèle, un thread est créé qui charge un petit programme eBPF, qui se bloque à l'étape après vérification du pseudocode eBPF, mais avant sa compilation JIT.
Dans l'espace de noms d'ID utilisateur non privilégié, le fichier / proc / self / mountinfo s'ouvre et lit le chemin de répertoire long monté avec bind-mount, ce qui entraîne l'écriture de la ligne " // supprimé " dans la région avant le démarrage du tampon. La position d'écriture de la ligne est choisie de manière à écraser l'instruction dans le programme eBPF déjà testé mais pas encore compilé.
De plus, au niveau du programme eBPF, l'écriture incontrôlée hors du tampon est transformée en une capacité de lecture/écriture contrôlé dans d'autres structures du noyau en manipulant les structures btf et map_push_elem.
L'exploit place alors le tampon modprobe_path [] dans la mémoire du noyau et écrase le chemin "/ sbin / modprobe" dans celui-ci, permettant à tout fichier exécutable d'être lancé en tant que root si un appel request_module () est effectué, qui est exécuté par exemple lors de la création une prise netlink...
Les chercheurs ont fourni plusieurs solutions qui ne sont efficaces que pour un exploit spécifique, mais elles ne résolvent pas le problème lui-même.
En tant que tel, il est recommandé de définir le paramètre "/proc/sys/kernel/unprivileged_userns_clone" sur 0 pour désactiver le montage des répertoires dans un espace de noms d'ID utilisateur séparé et "/proc sys/kernel/unprivileged_bpf_disabled" sur 1 pour désactiver le chargement des programmes eBPF dans le noyau.
En plus du fait qu'il est également recommandé à tous les utilisateurs d'une distribution Linux de mettre à jour leur système pour disposer du patch correspondant. Le problème est évident depuis juillet 2014 et cela affecte les versions du noyau depuis 3.16. Le correctif de vulnérabilité a été coordonné avec la communauté et accepté dans le noyau le 19 juillet.
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter le détails dans le lien suivant.