La société Qualys a identifié deux vulnérabilités dans les outils apport (CVE-2025-5054) et systemd-coredump (CVE-2025-4598), utilisés pour traiter les fichiers core générés après l'arrêt brutal des processus. Ces vulnérabilités permettent d'accéder aux fichiers core sauvegardés après l'arrêt brutal des applications suid ou de certains processus systèmes en arrière-plan, qui peuvent contenir des identifiants d'utilisateur en cache ou des clés de chiffrement. L'outil apport est automatiquement appelé pour sauvegarder les core dumps sous Ubuntu, tandis que systemd-coredump est utilisé dans Red Hat Enterprise Linux 9+, Fedora et de nombreuses autres distributions Linux.
Une technique d'attaque a été démontrée, dans laquelle des conditions étaient créées pour l'arrêt brutal de l'application suid unix_chkpwd et l'accès au fichier core contenant le dump d'état au moment de l'échec. Le core dump sauvegardé contenait des hachages des mots de passe des utilisateurs du système, restant en mémoire après le chargement du contenu de /etc/shadow. La possibilité d'exploiter ces vulnérabilités a été démontrée sous Ubuntu 24.04 et Fedora 40/41, mais il est supposé que d'autres distributions sont également exposées à des attaques similaires.
Les deux vulnérabilités sont causées par une condition de course, permettant de remplacer le processus suid ayant échoué par un autre processus juste après le début du traitement de l'arrêt par le noyau, mais avant la vérification par le gestionnaire en espace utilisateur des paramètres du processus via /proc/pid/files. L'appel à apport et systemd-coredump se fait de la manière suivante : le noyau, après avoir obtenu des informations sur l'échec du processus, appelle le gestionnaire spécifié dans le fichier /proc/sys/kernel/core_pattern, puis lui transmet le contenu du core dump via un flux d'entrée.
La génération du core dump et l'exécution du gestionnaire ne se produisent pas immédiatement et ce délai est suffisant pour remplacer le processus suid échoué par un processus utilisateur ordinaire. En cas de remplacement, le gestionnaire de core dumps en cours d'exécution considérera que la panne s'est produite non pas dans le processus suid, mais dans une application utilisateur ordinaire et, en conséquence, sauvegardera le fichier core avec un accès possible pour un utilisateur ordinaire, et non uniquement pour l'administrateur.
L'attaque sur apport se résume aux étapes suivantes :
- Un nouveau processus est forké et la fonction execve() est appelée pour exécuter un programme suid, tel que unix_chkpwd.
- Le temps nécessaire pour charger les données confidentielles dans la mémoire par le programme suid est omis (dans le cas de unix_chkpwd, le chargement des hachages de mots de passe de tous les utilisateurs du système depuis le fichier /etc/shadow est attendu).
- Avant que la commande ne soit exécutée, un signal SIGSEGV ou SIGSYS est envoyé au processus pour terminer de manière anormale.
- En réponse à cette interruption anormale, le noyau génère un core dump et lance le processus apport pour traiter le core dump dans l'espace utilisateur.
- Après le lancement d'apport, mais avant le début de l'analyse, un signal SIGKILL est envoyé au processus en échec, et le processus lui-même est remplacé par un autre sans le drapeau suid. Pour contourner les vérifications dans apport, un nouveau processus est créé à l'intérieur d'espaces de noms séparés (user, pid et mount namespace).
- apport se connecte au socket unix /run/apport.socket dans l'espace de noms de points de montage créé pour le nouveau processus et envoie un descripteur de fichier pour accéder au core dump.
Pour obtenir l'identifiant nécessaire pour le nouveau processus, correspondant à l'identifiant du processus suid, le processus suid est arrêté par un signal SIGSTOP avant l'envoi du signal SIGSEGV, et pendant cet arrêt, de nouveaux processus sont lancés de manière répétée jusqu'à ce qu'un PID dont le numéro est proche du processus suid soit obtenu. Après le décalage de la numérotation du PID, les signaux SIGSEGV et SIGCONT sont envoyés au processus suid, après quoi SIGKILL est envoyé et de nouveaux processus sont lancés de manière circulaire pour atteindre le même PID que celui du processus suid.
En ce qui concerne systemd-coredump, il est plus facile de mener une attaque, car il n'est pas nécessaire de remplacer le processus suid par un processus dans un espace utilisateur distinct, il suffit d'obtenir une correspondance des AT_UID et AT_EUID. D'autre part, systemd-coredump est écrit en C et se lance assez rapidement, ce qui laisse moins de temps pour la substitution, contrairement à apport, qui est écrit en Python et charge divers fichiers pyc lors de l'initialisation. Ce problème est résolu en ralentissant artificiellement systemd-coredump : lors de l'appel du fichier suid, un très grand nombre d'arguments de ligne de commande est transmis, ce qui crée le retard nécessaire survenant lors de l'analyse de /proc/pid/cmdline.
Dans le cadre de l'analyse des vulnérabilités, les chercheurs ont également découvert que systemd-coredump, lors de l'appel de configuration, ne spécifie pas le drapeau «%d» dans /proc/sys/kernel/core_pattern, permettant à un attaquant de provoquer des arrêts inattendus de processus en arrière-plan exécutés avec des droits root et dérivant d'autres processus tout en changeant l'identifiant d'utilisateur pour un utilisateur non privilégié sous lequel l'attaque est effectuée. Cette possibilité permet d'attaquer non seulement les applications setuid, mais aussi des processus tels que sshd-session (OpenSSH), sd-pam (systemd) et cron, afin d'obtenir des données sensibles qui se retrouvent dans leur mémoire, telles que des clés privées, des hachages de mots de passe dans /etc/shadow, des marqueurs canari de la pile et des données pour contourner la randomisation de l'espace d'adressage (ASLR).
Il est possible de suivre la publication des mises à jour des paquets dans les distributions sur les pages suivantes : Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo, Arch. Comme solution pour bloquer les vulnérabilités, il est recommandé de désactiver la sauvegarde des core-dumps pour les programmes suid et les processus déconstruisant les privilèges, en définissant le paramètre /proc/sys/fs/suid_dumpable à 0. Pour une résolution complète du problème, des modifications doivent être apportées au noyau Linux, implémentant la possibilité de transmettre des informations sur un processus ayant échoué via le mécanisme pidfd (pidfd est lié à des processus spécifiques et, contrairement au pid, n'est pas réattribué).
Source : opennet.ru
