Les responsables d'OpenSSH ont publié des mises à jour de sécurité pour contenir une faille de sécurité critique qui pourrait conduire à l'exécution de code à distance non authentifié avec les privilèges root sur les systèmes Linux basés sur la glibc.
La vulnérabilité a reçu l'identifiant CVE CVE-2024-6387. Il réside dans Composant serveur OpenSSH , également connu sous le nom de sshd, conçu pour écouter les connexions de n'importe quelle application client.
"La vulnérabilité, qui est une condition de concurrence critique du gestionnaire de signaux sur le serveur OpenSSH (sshd), permet l'exécution de code à distance (RCE) non authentifié en tant que root sur les systèmes Linux basés sur la glibc", a-t-il déclaré. Bharat Jogi, directeur principal de l'unité de recherche sur les menaces de Qualys. dans un communiqué publié aujourd'hui. "Cette condition de concurrence critique affecte sshd dans sa configuration par défaut."
Une condition de concurrence critique est une situation dans laquelle le comportement du logiciel dépend de la séquence ou du timing des opérations non synchronisées. Ce problème se produit souvent dans les systèmes simultanés ou multithread, où deux ou plusieurs processus ou threads tentent d'accéder ou de modifier une ressource partagée en même temps. Si elles ne sont pas gérées correctement, les conditions de concurrence peuvent entraîner un comportement imprévisible, des erreurs de programmation et des failles de sécurité. Dans le domaine de la sécurité, une condition de concurrence critique peut être exploitée par un attaquant pour effectuer des actions non autorisées, accéder à des données sensibles ou compromettre l'intégrité du système, rendant essentielle la mise en œuvre de techniques de synchronisation et de contrôle d'accès adéquates.
La société de cybersécurité a déclaré avoir identifié pas moins de 14 millions d'instances de serveur OpenSSH potentiellement vulnérables exposées sur Internet, ajoutant qu'il s'agit d'une réversion d'une faille vieille de 18 ans déjà corrigée et identifiée comme CVE-2006-5051 , le problème étant résolu en octobre 2020. dans le cadre de la version 8.5p1 d'OpenSSH.
« Une exploitation réussie a été démontrée sur les systèmes Linux/glibc 32 bits avec [ randomisation de la disposition de l'espace d'adressage ]", dit OpenSSH dans un avertissement. "Dans des conditions de laboratoire, l'attaque nécessite en moyenne 6 à 8 heures de connexions continues jusqu'au maximum accepté par le serveur."
La vulnérabilité affecte les versions comprises entre 8.5p1 et 9.7p1. Les versions antérieures à 4.4p1 sont également vulnérables au bug de condition de concurrence, à moins qu'elles ne soient corrigées pour CVE-2006-5051 et CVE-2008-4109 . Il est à noter que les systèmes OpenBSD ne sont pas concernés, car ils incluent un mécanisme de sécurité qui bloque la faille.
Plus précisément, Qualys a découvert que si un client ne parvient pas à s'authentifier dans les 120 secondes (paramètre défini par LoginGraceTime), le gestionnaire SIGALRM de sshd est appelé de manière asynchrone, d'une manière qui n'est pas courante. sécurité du signal asynchrone .
L’effet net de l’exploitation de CVE-2024-6387 est une compromission et un contrôle complets du système, permettant aux acteurs malveillants d’exécuter du code arbitraire avec les privilèges les plus élevés, de contourner les mécanismes de sécurité, de voler des données et même de maintenir un accès persistant.
"Une faille, une fois corrigée, est réapparue dans une version ultérieure du logiciel, généralement en raison de modifications ou de mises à jour qui réintroduisent le problème par inadvertance", a déclaré Jogi. "Cet incident met en évidence le rôle crucial de tests de régression approfondis pour empêcher la réintroduction de vulnérabilités connues dans l'environnement."
Bien que la vulnérabilité présente des obstacles importants en raison de sa nature de condition de concurrence à distance, il est conseillé aux utilisateurs d'appliquer les derniers correctifs pour se protéger des menaces potentielles.. Nous recommandons également de limiter l'accès SSH via des contrôles basés sur le réseau tels que le pare-feu et l'application d'une segmentation du réseau pour limiter les accès non autorisés et les mouvements latéraux.
