L'entreprise Qualys a identifié une vulnérabilité critique (CVE-2024-6387) dans OpenSSH, permettant l'exécution à distance de code avec des droits root sans passer par l'authentification. Cette vulnérabilité, surnommée regreSSHion, se manifeste dans la configuration par défaut à partir de la version OpenSSH 8.5 sur les systèmes utilisant la bibliothèque standard Glibc.
La possibilité de mener une attaque a été démontrée sur un système 32 bits utilisant Glibc avec la protection ASLR activée (randomisation de l'espace d'adresses). Pour réussir une attaque dans des conditions de laboratoire, il a fallu 6 à 8 heures, pendant lesquelles des connexions étaient établies en continu à la capacité maximale de configuration sshd. serveur L'attaque est simplifiée et nécessite moins de temps sur des systèmes sans ASLR ou sur des distributions utilisant une version modifiée d'OpenSSH, où la re-randomisation ASLR pour chaque connexion est désactivée. Il a été décidé de ne pas publier le prototype fonctionnel de l'exploit avant que la vulnérabilité ne soit largement corrigée, mais il existe une description suffisamment détaillée de la vulnérabilité, rendant l'apparition d'exploits tiers une question de temps.
Il est également possible de mener une attaque sur des systèmes 64 bits, mais l'exploit fonctionnel pour ces systèmes n'est pas encore prêt. On suppose que l'attaque sur les systèmes 64 bits prendra beaucoup plus de temps, mais pas plus d'une semaine. OpenSSH sur OpenBSD n'est pas affecté par ce problème, car depuis 2001, ce système utilise un mécanisme de protection qui bloque ce type d'attaques. Dans d'autres systèmes utilisant des bibliothèques standard différentes de Glibc, une adaptation de la méthode pour réaliser l'attaque est théoriquement possible (ce point n'a pas encore été étudié par Qualys).
La vulnérabilité a été corrigée dans la version publiée aujourd'hui d'OpenSSH 9.8 (patch). Les mises à jour des paquets dans les distributions peuvent être suivies sur les pages suivantes : Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, ROSA, Gentoo, ALT Linux, Arch et FreeBSD. Comme solution de contournement pour bloquer la vulnérabilité dans sshd_config, il est possible de définir le paramètre « LoginGraceTime=0 », bien que la désactivation du délai d'attente facilite l'initiation d'une attaque par déni de service en établissant un grand nombre de connexions dépassant les limites définies par le paramètre MaxStartups.
L'un des signes d'une tentative d'attaque est l'apparition dans les journaux d'un grand nombre d'entrées « Timeout before authentication ».
La vulnérabilité est survenue à la suite d'un changement régressif inclus dans la version OpenSSH 8.5, entraînant une condition de course dans le code de gestion des signaux dans sshd. Cette régression a conduit à la désactivation de la protection contre une ancienne vulnérabilité CVE-2006-5051, qui se manifestait jusqu'à la version OpenSSH 4.4 (2006) et avait un caractère théorique.
Dans le cadre du développement d'OpenSSH 8.5, par erreur, le bloc « #ifdef DO_LOG_SAFE_IN_SIGHAND » a été supprimé de la fonction sigdie(), qui est directement appelée par le gestionnaire SIGALRM.
Le gestionnaire SIGALRM est appelé dans sshd en mode asynchrone, si le client n'a pas terminé son authentification dans le temps imparti par le délai de connexion (LoginGraceTime, par défaut 120 sec). L'attaque repose sur le fait que le gestionnaire de signaux appelle des fonctions non sécurisées lors du traitement asynchrone des signaux, telles que syslog(). La fonction syslog() dans Glibc n'est pas conçue pour être utilisée dans des gestionnaires de signaux exécutés de manière asynchrone, car elle appelle des fonctions malloc() et free(). Le déclenchement du signal SIGALRM, interrompant l'exécution d'un certain code dans sshd, peut entraîner une corruption de l'état d'exécution, et l'objectif de l'exploit est de créer des conditions pour interrompre le code souhaité au bon moment de son exécution. La vulnérabilité n'affecte pas OpenBSD, car dans ce dernier, au lieu de syslog() depuis le gestionnaire de signal SIGALRM, la fonction syslog_r() est appelée, spécialement conçue pour une exécution asynchrone.
Source : opennet.ru
