Il y a quelques jours, on a appris que l'équipe d'enquête de Qualys a découvert une vulnérabilité de déni de service en raison de l'épuisement de la pile dans systemd, donc tout utilisateur non privilégié peut exploiter cette vulnérabilité pour bloquer systemd.
Vulnérabilité déjà catalogué comme (CVE-2021-33910) Il est mentionné que cela affecte systemd est causé par un échec lors de la tentative de montage d'un répertoire avec une taille de chemin supérieure à 8 Mo via FUSE et dans lequel le processus d'initialisation de contrôle (PID1) manque de mémoire de pile et se bloque, mettant le système dans un état de "panique".
Esta vulnerabilidad se introdujo en systemd v220 (abril de 2015) mediante el compromiso 7410616c («núcleo: lógica de validación y manipulación del nombre de la unidad de reelaboración»), que reemplazó un strdup () en el montón por un strdupa () en la pile. L'exploitation réussie de cette vulnérabilité permet à tout utilisateur non privilégié de provoquer un déni de service via la panique du noyau.
Dès que l'équipe de recherche de Qualys a confirmé la vulnérabilité, Qualys a participé à la divulgation responsable de la vulnérabilité et s'est coordonné avec l'auteur et les distributions open source pour annoncer la vulnérabilité.
Les chercheurs mentionnent que le problème liée à CVE-2021-33910 est due au fait que systemd surveille et analyse le contenu de / proc / self / mountinfo et il gère chaque point de montage dans la fonction unit_name_path_escape () qui provoque l'exécution d'une opération appelée "strdupa ()" qui prend en charge l'allocation des données sur la pile au lieu du tas.
C'est pourquoi depuis la taille de pile maximale autorisée est limitée par la fonction "RLIMIT_STACK", la gestion d'un chemin trop long vers le point de montage provoque le blocage du processus "PID1" ce qui entraîne l'arrêt du système.
De plus, ils mentionnent que pour qu'une attaque soit fonctionnelle, le module FUSE le plus simple peut être utilisé en combinaison avec l'utilisation d'un répertoire fortement imbriqué comme point de montage, dont la taille du chemin dépasse 8 Mo.
Aussi Il est important de mentionner que les chercheurs Qualys faire mention d'un cas particulier avec vulnérabilité, car surtout avec systemd version 248, l'exploit n'est pas fonctionnel en raison d'un bogue présent dans le code systemd qui provoque l'échec de / proc / self / mountinfo. Il est également intéressant de noter qu'une situation très similaire s'est produite en 2018, comme en essayant d'écrire un exploit pour la vulnérabilité CVE-2018-14634 dans le noyau Linux, dans laquelle les chercheurs de Qualys ont trouvé trois autres vulnérabilités critiques dans systemd.
À propos de la vulnérabilité l'équipe Red Hat a mentionné tout produit conforme à RHEL sera également potentiellement affecté.
Ceci comprend:
- Conteneurs de produits basés sur des images de conteneurs RHEL ou UBI. Ces images sont mises à jour régulièrement, et l'état du conteneur indiquant si un correctif est disponible pour cette faille peut être consulté dans le Container Health Index, qui fait partie du Red Hat Container Catalog (https://access.redhat.com/containers) .
- Produits qui extraient des packages du canal RHEL. Assurez-vous que le package systemd sous-jacent de Red Hat Enterprise Linux est à jour dans ces environnements de produit.
En raison de l'étendue de la surface d'attaque de cette vulnérabilité, Qualys recommande aux utilisateurs d'appliquer les correctifs appropriés (qui ont déjà été publiés il y a quelques jours) pour cette vulnérabilité immédiatement.
Comme déjà mentionné, le problème est apparu depuis systemd 220 (avril 2015) et a déjà été corrigé dans le référentiel principal de systemd et a été corrigé sur la plupart des distributions Linux principal, ainsi que ses dérivés, vous pouvez vérifier l'état dans les liens suivants (Debian, Ubuntu, Fedora, RHEL, SUSE, voûte).
Enfin, si vous souhaitez en savoir plus à propos de cette vulnérabilité, vous pouvez en vérifier les détails dans le lien suivant.