Une nouvelle vulnérabilité a été découverte dans Systemd

Une vulnérabilité a été trouvée dans systemd qui est déjà décrite dans (CVE-2019-6454), Quoi permet de bloquer le processus d'initialisation de la commande (PID1) lors de l'envoi d'un message spécialement conçu à un utilisateur non privilégié via le D-Bus.

Les Les développeurs Red Hat n'excluent pas non plus la possibilité d'utiliser la vulnérabilité pour organiser l'exécution de code avec les privilèges root., mais la possibilité finale d'une telle attaque n'a pas encore été déterminée.

À propos de systemd

Pour ceux qui ne connaissent pas Systemd Je peux te dire ça il s'agit d'un système d'initialisation Linux et d'un gestionnaire de services qui inclut des fonctionnalités telles que le démarrage du démon à la demande, le montage automatique et la maintenance des points de montage, la prise en charge des instantanés et le suivi des processus à l'aide de groupes de contrôle Linux.

Systemd fournit un démon de registre et d'autres outils et utilitaires pour vous aider dans les tâches d'administration système courantes. Lennart Poettering et Kay Sievers ont écrit SystemD, inspiré de macOS launchd et Upstart, dans le but de créer un système moderne et dynamique.

En particulier, systemd offre des capacités de parallélisation agressives et une logique de contrôle de service basée sur les dépendances, permettant aux services de démarrer en parallèle et accélérant les temps de démarrage. Ces deux aspects étaient présents dans Upstart, mais améliorés par systemd.

Systemd est le système de démarrage par défaut pour les principales distributions Linux, mais il est rétrocompatible avec les scripts de démarrage SysV.

SysVinit est un système d'initialisation qui précède systemd et utilise une approche simplifiée pour démarrer le service. Systemd gère non seulement l'initialisation du système, mais fournit également des alternatives à d'autres utilitaires bien connus tels que cron et syslog.

À propos de la nouvelle vulnérabilité systemd

En manipulant la taille du message envoyé via le D-Bus, un attaquant peut déplacer le pointeur au-delà des limites de mémoire allouées à la pile, contournant la protection de "stack guard-page", qui est basée sur la substitution d'une page mémoire à la périphérie qui appelle une exception (page fault).

L'attaque réussie est démontrée sur Ubuntu 18.10 avec systemd 239 et sur CentOS 7.6 avec systemd 219.

Pour contourner ce problème, la compilation peut être utilisée dans GCC avec l'option "-fstack-clash-protection", qui est utilisée par défaut dans Fedora 28 et 29.

Il est à noter qu'en 2014 l'auteur de la bibliothèque système MUSL a signalé parmi les principaux problèmes architecturaux systemd inflation excessive du gestionnaire PID1 et a remis en question la faisabilité de l'implémentation d'une API de contrôleur de niveau PID1 pour Link with the Bus, car c'est un vecteur sérieux pour attaques et peuvent nuire à la fiabilité de l'ensemble du système

Selon un chercheur en sécurité qui a révélé une vulnérabilité, un changement de pointeur de pile n'est possible que pour les pages mémoire inutilisées (non assigné), qui ne permet pas d'organiser l'exécution de code dans le contexte du processus PID1, mais permet à un attaquant d'initier le verrou PID1 avec une transition ultérieure du noyau Linux à l'état "panique" (dans le cas du contrôleur PID 1 échec, l'ensemble du système se bloque).

Dans systemd, un gestionnaire de signaux est installé qui tente de piéger les défauts du processus PID1 (erreur de segmentation) et démarre le shell pour la récupération.

Mais comme, pendant l'attaque, un appel est fait à des pages de mémoire non dupliquées (non allouées), le noyau ne peut pas appeler ce gestionnaire de signal et termine simplement le processus avec PID 1, ce qui à son tour fait Il est impossible de continuer à travailler et d'entrer dans l'état "panique", donc un redémarrage du système est nécessaire.

Il existe déjà une solution au problème

Comme tout problème de sécurité déjà décrit et signalé, sa publication ne peut être faite tant que le problème n'a pas été résolu et des mises à jour de correctifs de vulnérabilité pour SUSE / openSUSE, Fedora ont déjà été publiées, également pour Ubuntu et en partie pour Debian (Debian Stretch uniquement).
Bien que le problème reste non corrigé dans RHEL.