SSHole — une vulnérabilité qui permet de se connecter via SSH sans mot de passe sur les systèmes utilisant Musl

Les développeurs d'OpenSSH ont publié une mise à jour urgente OpenSSH 10.6p2, qui ajoute une protection contre une vulnérabilité critique (CVE non attribué), nommée « SSHole », permettant de contourner l'authentification. Dans les systèmes utilisant la bibliothèque Musl, cette vulnérabilité permet de se connecter à un utilisateur sans mot de passe en entrant un mot de passe contenant plus de 256 caractères. Ce problème concerne les distributions Linux utilisant la bibliothèque standard musl, mais sans utiliser PAM (Pluggable Authentication Modules), telles que OpenWRT, Alpine, Buildroot et Yocto. Il est particulièrement préoccupant que l'accès par mot de passe soit souvent bloqué pour l'utilisateur root, ce qui permet à quiconque de se connecter à distance avec des privilèges d'administrateur.

La faille menant à cette vulnérabilité n'est pas dans le code d'OpenSSH, mais est exploitée via sshd. Étant donné la gravité du problème, une solution de contournement pour bloquer la vulnérabilité a été proposée dans la version OpenSSH 10.6p2. Il est recommandé aux propriétaires de systèmes vulnérables de ne pas attendre des mises à jour, mais de désactiver immédiatement l'authentification par mot de passe via l'option « PasswordAuthentication no » dans /etc/ssh/sshd_config ou de désactiver complètement SSH.

Le problème ne se manifeste pas dans les systèmes autres que Linux, ni dans les environnements Linux basés sur glibc, et encore moins dans les systèmes utilisant PAM pour l'authentification par mot de passe. Un correctif est déjà disponible dans Alpine et OpenWRT.

La vulnérabilité est liée à l'interaction incorrecte entre OpenSSH et la fonction crypt() de musl. Pour protéger contre la détermination de l'existence d'utilisateurs par l'analyse des différences dans le temps de traitement des requêtes, depuis 2016, OpenSSH utilise la procédure de vérification par défaut lors de la vérification des comptes sans mot de passe : il appelle la fonction « crypt(mot_de_passe_transmis, sel) » avec le sel d'un autre utilisateur ayant un hachage de mot de passe valide, puis compare le hachage retourné par la fonction crypt avec la valeur du champ contenant le hachage du mot de passe.

Cependant, dans musl, la fonction crypt() pour les hachages SHA-512 retourne le caractère « * » si la longueur du mot de passe transmis dépasse 256 octets (une limite mise en place en 2012 pour se protéger contre les attaques par déni de service, car le transfert de grandes valeurs impose une grande charge au CPU). Ce même symbole est utilisé dans le champ contenant le hachage du mot de passe dans « /etc/shadow » pour indiquer que l'authentification par mot de passe est bloquée pour les comptes.

En conséquence, un attaquant capable de se connecter à un serveur SSH peut accéder à n'importe quel compte dont le champ mot de passe dans «/etc/shadow» contient le symbole «*», en transmettant une chaîne d'une longueur de 257 à 1024 octets. Ce problème concerne de nombreuses images Docker existantes, construites à l'aide d'Alpine Linux, ainsi que les images standard Alpine pour les systèmes cloud AWS et Azure, où le signe «*» est affiché à la place du hachage du mot de passe pour l'utilisateur root.

Il est intéressant de noter que dans les images Docker officielles utilisant Alpine, un mot de passe root vide a été utilisé depuis 2015. Après la découverte de ce fait, un symbole «!» a été mis à la place du hachage du mot de passe. Cependant, sa présence bloquait l'accès par clés SSH, c'est pourquoi depuis 2022, le symbole pour bloquer l'accès par mot de passe a été remplacé par «*».

Source : opennet.ru