Deux vulnérabilités repérées dans Ubuntu, Fedora et RHEL peuvent permettre à un attaquant local de lire des données sensibles en exploitant un crash de programme. Le scénario est pointu, mais les conséquences peuvent être sérieuses si les systèmes ne sont pas corrigés.

- Deux failles dans Ubuntu, Fedora et RHEL permettent à un attaquant local d'accéder à des données sensibles.
- Les vulnérabilités exploitent une race condition dans la gestion des core dumps, exposant des informations critiques.
- Bien que le risque soit faible, il est conseillé de désactiver les core dumps pour les programmes SUID en attendant.
Il suffit parfois d’une simple erreur de synchronisation dans la gestion d’un plantage pour dévoiler des informations sensibles stockées sur un système. C’est ce que viennent de montrer les chercheurs de Qualys, en documentant deux failles affectant la gestion des « core dumps » – ces fichiers générés automatiquement lorsqu’un programme plante sous Linux. En combinant permissions mal configurées et comportement imprévisible, il est possible, dans certains cas, d’accéder au contenu mémoire d’un programme exécuté avec les droits root. Y compris à des éléments aussi critiques que les hashs de mots de passe.
Quand le système attribue le mauvais fichier mémoire au mauvais programme
Les deux vulnérabilités, référencées sous les noms CVE-2025-5054 (CVSS 4.7) et CVE-2025-4598 (CVSS 4.7), concernent respectivement les outils Apport (utilisé notamment par Ubuntu) et systemd-coredump (activé par défaut sur Fedora et RHEL). Tous deux sont conçus pour gérer les rapports de crash, et génèrent un core dump (copie de la mémoire du programme au moment du plantage).
Or, il s’avère qu’un attaquant local peut tirer parti d’un comportement inattendu, même sans droit admin. Le problème repose sur ce qu’on appelle une race condition, c'est-à-dire une situation de concurrence au cours de laquelle deux opérations s’exécutent presque en même temps, et où l’ordre dans lequel elles se produisent peut changer le résultat final.
Ici, ce conflit d’exécution oppose le moment où un programme SUID plante (à savoir un programme qui, même lancé par un utilisateur sans privilège, s’exécute avec les droits du propriétaire du fichier, souvent root), et celui où un autre programme non privilégié réutilise le même identifiant de processus (PID).
Si ce recyclage de PID est suffisamment rapide, Apport ou systemd-coredump peuvent confondre les deux programmes et attribuer par erreur le core dump du programme SUID à celui lancé par l’attaquant. Ce dernier accède alors à la copie mémoire du processus initial, qui peut contenir des éléments sensibles, comme des données personnelles, des clés de chiffrement, des informations système… et dans le cas testé par Qualys, les hashs de mots de passe stockés dans /etc/shadow
. Oups.

Peu de risques en pratique, mais une bonne raison de se protéger
Les distributions concernées incluent Ubuntu 16.04 à 24.04 (via Apport jusqu'à la version 2.33.0), Fedora 40/41, ainsi que Red Hat Enterprise Linux 9/10. Debian n’est pas affectée par défaut, sauf si systemd-coredump a été installé manuellement. Amazon Linux et Gentoo ont également publié des avis de sécurité.
À noter que Red Hat classe la faille comme de gravité modérée, estimant que ses conditions d’exploitation sont trop spécifiques pour représenter une menace généralisée : accès local requis, race condition parfaitement maîtrisée, et programme SUID susceptible de planter.
Malgré tout, le risque existe. En attendant les correctifs, vous pouvez déjà désactiver, en préventif, la génération de core dumps pour les programmes SUID, via le terminal, avec les droits root :
echo 0 > /proc/sys/fs/suid_dumpable
Alors, certes. Ces failles ne toucheront sans doute qu’un public restreint, mais elles montrent qu’une simple mécanique système mal maîtrisée peut suffire à exposer des données sensibles. Sur les postes partagés, dans les environnements de test ou sur les serveurs, pensez à garder un œil sur les correctifs à venir, et installez-les dès leur mise à disposition.
Sources : Qualys, The Hacker News
03 mars 2025 à 10h05