{"id":117137,"date":"2024-07-09T15:43:01","date_gmt":"2024-07-09T13:43:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-paketah-s-openssh-iz-sostava-rhel-9-dopuskayushhaya-udalyonnoe-vypolnenie-koda"},"modified":"2024-07-09T15:43:01","modified_gmt":"2024-07-09T13:43:01","slug":"uyazvimost-v-paketah-s-openssh-iz-sostava-rhel-9-dopuskayushhaya-udalyonnoe-vypolnenie-koda","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/uyazvimost-v-paketah-s-openssh-iz-sostava-rhel-9-dopuskayushhaya-udalyonnoe-vypolnenie-koda","title":{"rendered":"Vuln\u00e9rabilit\u00e9 dans les paquets OpenSSH inclus dans RHEL 9, permettant l'ex\u00e9cution de code \u00e0 distance","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dans le cadre de l'examen de la vuln\u00e9rabilit\u00e9 critique identifi\u00e9e la semaine derni\u00e8re dans OpenSSH, une autre vuln\u00e9rabilit\u00e9 similaire a \u00e9t\u00e9 d\u00e9couverte (CVE-2024-6409), permettant l'ex\u00e9cution \u00e0 distance de code sans passer par l'authentification. La nouvelle vuln\u00e9rabilit\u00e9 n'est pas aussi grave que la pr\u00e9c\u00e9dente, car elle se manifeste apr\u00e8s une \u00e9l\u00e9vation de privil\u00e8ges dans un processus fils lanc\u00e9 par le serveur SSH. Cette vuln\u00e9rabilit\u00e9 est pr\u00e9sente dans les paquets openssh de la distribution Red Hat Enterprise Linux 9, bas\u00e9s sur la version d'OpenSSH 8.7 publi\u00e9e en 2021. Le probl\u00e8me touche \u00e9galement les paquets pour Fedora Linux 36 et 37, fond\u00e9s sur les versions OpenSSH 8.7 et 8.8. <\/p>\n
Essentiellement, cette vuln\u00e9rabilit\u00e9 est similaire au probl\u00e8me pr\u00e9c\u00e9dent et est \u00e9galement caus\u00e9e par une condition de comp\u00e9tition dans le gestionnaire d'interruption SIGALRM, r\u00e9sultant de l'ex\u00e9cution de fonctions non con\u00e7ues pour \u00eatre appel\u00e9es en mode asynchrone depuis des gestionnaires de signaux. Le gestionnaire se d\u00e9clenche lorsque le d\u00e9lai imparti, d\u00e9fini par le param\u00e8tre LoginGraceTime, est atteint, interrompant l'ex\u00e9cution actuelle du code. L'utilisation de fonctions non con\u00e7ues pour une ex\u00e9cution asynchrone, qui utilisent l'allocation dynamique de m\u00e9moire, telles que syslog(), peut endommager les structures internes de malloc lorsque SIGALRM se d\u00e9clenche durant l'ex\u00e9cution d'un code sp\u00e9cifique. <\/p>\n
La nouvelle vuln\u00e9rabilit\u00e9 se distingue par le fait que la condition de comp\u00e9tition se produit en raison de l'appel, dans le gestionnaire de signaux grace_alarm_handler(), de la fonction cleanup_exit(). Dans la base de code principale d'OpenSSH, cette fonction peut \u00eatre utilis\u00e9e dans un code ex\u00e9cut\u00e9 de mani\u00e8re asynchrone, mais dans les paquets destin\u00e9s \u00e0 RHEL 9 et Fedora, un patch suppl\u00e9mentaire a \u00e9t\u00e9 appliqu\u00e9, ajoutant un appel \u00e0 cette fonction pour g\u00e9n\u00e9rer des \u00e9v\u00e9nements d'audit, pr\u00e9vu pour utilisation dans les gestionnaires de signaux. <\/p>\n
Ce correctif a \u00e9t\u00e9 utilis\u00e9 dans RHEL 9 et ses distributions d\u00e9riv\u00e9es dans des paquets bas\u00e9s sur OpenSSH 8.7p1. Dans les versions r\u00e9centes de Fedora, le probl\u00e8me ne se manifeste pas, car \u00e0 partir de Fedora 38, la distribution a migr\u00e9 vers une version plus r\u00e9cente d'OpenSSH sans modification de cleanup_exit(). Contrairement \u00e0 la vuln\u00e9rabilit\u00e9 pr\u00e9c\u00e9dente, un contournement bas\u00e9 sur l'utilisation de l'option «-e» dans sshd, qui d\u00e9sactive la sortie des journaux via syslog, n'est pas ad\u00e9quat pour bloquer le nouveau probl\u00e8me. Cependant, pour contrer la vuln\u00e9rabilit\u00e9, il est possible de configurer le param\u00e8tre «LoginGraceTime=0» dans sshd_config. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"