La soci\u00e9t\u00e9 Qualys a identifi\u00e9 deux vuln\u00e9rabilit\u00e9s dans les outils apport (CVE-2025-5054) et systemd-coredump (CVE-2025-4598), utilis\u00e9s pour traiter les fichiers core g\u00e9n\u00e9r\u00e9s apr\u00e8s l'arr\u00eat brutal des processus. Ces vuln\u00e9rabilit\u00e9s permettent d'acc\u00e9der aux fichiers core sauvegard\u00e9s apr\u00e8s l'arr\u00eat brutal des applications suid ou de certains processus syst\u00e8mes en arri\u00e8re-plan, qui peuvent contenir des identifiants d'utilisateur en cache ou des cl\u00e9s de chiffrement. L'outil apport est automatiquement appel\u00e9 pour sauvegarder les core dumps sous Ubuntu, tandis que systemd-coredump est utilis\u00e9 dans Red Hat Enterprise Linux 9+, Fedora et de nombreuses autres distributions Linux. <\/p>\n
Une technique d'attaque a \u00e9t\u00e9 d\u00e9montr\u00e9e, dans laquelle des conditions \u00e9taient cr\u00e9\u00e9es pour l'arr\u00eat brutal de l'application suid unix_chkpwd et l'acc\u00e8s au fichier core contenant le dump d'\u00e9tat au moment de l'\u00e9chec. Le core dump sauvegard\u00e9 contenait des hachages des mots de passe des utilisateurs du syst\u00e8me, restant en m\u00e9moire apr\u00e8s le chargement du contenu de \/etc\/shadow. La possibilit\u00e9 d'exploiter ces vuln\u00e9rabilit\u00e9s a \u00e9t\u00e9 d\u00e9montr\u00e9e sous Ubuntu 24.04 et Fedora 40\/41, mais il est suppos\u00e9 que d'autres distributions sont \u00e9galement expos\u00e9es \u00e0 des attaques similaires. <\/p>\n
Les deux vuln\u00e9rabilit\u00e9s sont caus\u00e9es par une condition de course, permettant de remplacer le processus suid ayant \u00e9chou\u00e9 par un autre processus juste apr\u00e8s le d\u00e9but du traitement de l'arr\u00eat par le noyau, mais avant la v\u00e9rification par le gestionnaire en espace utilisateur des param\u00e8tres du processus via \/proc\/pid\/files. L'appel \u00e0 apport et systemd-coredump se fait de la mani\u00e8re suivante : le noyau, apr\u00e8s avoir obtenu des informations sur l'\u00e9chec du processus, appelle le gestionnaire sp\u00e9cifi\u00e9 dans le fichier \/proc\/sys\/kernel\/core_pattern, puis lui transmet le contenu du core dump via un flux d'entr\u00e9e. <\/p>\n
La g\u00e9n\u00e9ration du core dump et l'ex\u00e9cution du gestionnaire ne se produisent pas imm\u00e9diatement et ce d\u00e9lai est suffisant pour remplacer le processus suid \u00e9chou\u00e9 par un processus utilisateur ordinaire. En cas de remplacement, le gestionnaire de core dumps en cours d'ex\u00e9cution consid\u00e9rera que la panne s'est produite non pas dans le processus suid, mais dans une application utilisateur ordinaire et, en cons\u00e9quence, sauvegardera le fichier core avec un acc\u00e8s possible pour un utilisateur ordinaire, et non uniquement pour l'administrateur. <\/p>\n
L'attaque sur apport se r\u00e9sume aux \u00e9tapes suivantes : <\/p>\n
Pour obtenir l'identifiant n\u00e9cessaire pour le nouveau processus, correspondant \u00e0 l'identifiant du processus suid, le processus suid est arr\u00eat\u00e9 par un signal SIGSTOP avant l'envoi du signal SIGSEGV, et pendant cet arr\u00eat, de nouveaux processus sont lanc\u00e9s de mani\u00e8re r\u00e9p\u00e9t\u00e9e jusqu'\u00e0 ce qu'un PID dont le num\u00e9ro est proche du processus suid soit obtenu. Apr\u00e8s le d\u00e9calage de la num\u00e9rotation du PID, les signaux SIGSEGV et SIGCONT sont envoy\u00e9s au processus suid, apr\u00e8s quoi SIGKILL est envoy\u00e9 et de nouveaux processus sont lanc\u00e9s de mani\u00e8re circulaire pour atteindre le m\u00eame PID que celui du processus suid. <\/p>\n
En ce qui concerne systemd-coredump, d'une part, il est plus facile de mener une attaque contre lui, car il n'est pas n\u00e9cessaire de remplacer un processus suid par un processus dans un espace utilisateur s\u00e9par\u00e9, il suffit d'obtenir une correspondance entre AT_UID et AT_EUID. D'autre part, systemd-coredump est \u00e9crit en C et se lance assez rapidement, ce qui laisse moins de temps pour la substitution, contrairement \u00e0 apport, qui est \u00e9crit en Python et charge divers fichiers pyc pendant le processus d'initialisation. Ce probl\u00e8me peut \u00eatre r\u00e9solu en ralentissant artificiellement systemd-coredump \u2014 lors de l'appel d'un fichier suid, un grand nombre d'arguments de ligne de commande est transmis, ce qui cr\u00e9e le d\u00e9lai n\u00e9cessaire pendant l'analyse de \/proc\/pid\/cmdline. <\/p>\n
Lors de l'analyse des vuln\u00e9rabilit\u00e9s, les chercheurs ont \u00e9galement constat\u00e9 que systemd-coredump, lors de la configuration de l'appel, ne sp\u00e9cifie pas le drapeau \"%d\" dans \/proc\/sys\/kernel\/core_pattern, permettant \u00e0 un attaquant de provoquer une terminaison inattendue de processus d'arri\u00e8re-plan ex\u00e9cut\u00e9s avec des droits root et d\u00e9rivant d'autres processus en changeant l'identifiant utilisateur en un utilisateur non privil\u00e9gi\u00e9 sous lequel l'attaque est effectu\u00e9e. Cette possibilit\u00e9 permet de mener une attaque non seulement sur les applications setuid, mais aussi sur des processus tels que sshd-session (OpenSSH), sd-pam (systemd) et cron, afin d'acc\u00e9der \u00e0 des donn\u00e9es sensibles qui pourraient rester en m\u00e9moire, telles que des cl\u00e9s priv\u00e9es, des hachages de mots de passe dans \/etc\/shadow, des balises canary du stack et des donn\u00e9es pour contourner l'al\u00e9atoiring des adresses (ASLR). <\/p>\n