Après six mois de développement, la version OpenSSH 8.9 est présentée, une implémentation ouverte du client et du serveur pour travailler avec les protocoles SSH 2.0 et SFTP. Dans cette nouvelle version, une vulnérabilité a été corrigée dans sshd, permettant potentiellement d'accéder sans authentification. Le problème est causé par un dépassement d'entier dans le code d'authentification, mais son exploitation n'est possible qu'en combinaison avec d'autres erreurs logiques dans le code.
Dans son état actuel, la vulnérabilité n'est pas exploitable si le mode de séparation des privilèges est activé, puisque sa manifestation est bloquée par des vérifications distinctes effectuées dans le code de suivi de la séparation des privilèges. Le mode de séparation des privilèges a été activé par défaut en 2002, avec le début d'OpenSSH 3.2.2, et est obligatoire depuis la sortie d'OpenSSH 7.5, publiée en 2017. De plus, dans les versions portables d'OpenSSH à partir de la version 6.5 (2014), la vulnérabilité est bloquée lors de la compilation avec les drapeaux de protection contre les dépassements d'entiers.
Autres changements :
- Dans la version portable d'OpenSSH, le support intégré pour le hachage des mots de passe avec l'algorithme MD5 a été supprimé (un lien avec des bibliothèques externes comme libxcrypt est autorisé pour restituer cette fonctionnalité).
- Dans ssh, sshd, ssh-add et ssh-agent, un sous-système a été mis en œuvre pour restreindre le transfert et l'utilisation des clés ajoutées au ssh-agent. Ce sous-système permet de définir des règles précisant comment et où les clés peuvent être utilisées dans le ssh-agent. Par exemple, pour ajouter une clé qui peut être utilisée uniquement pour l'authentification lors de la connexion de tout utilisateur à l'hôte scylla.example.org, de l'utilisateur perseus à l'hôte cetus.example.org et de l'utilisateur medea à l'hôte charybdis.example.org avec redirection via l'hôte intermédiaire scylla.example.org, vous pouvez utiliser la commande suivante : $ ssh-add -h «perseus@cetus.example.org» \ -h «scylla.example.org» \ -h «scylla.example.org>medea@charybdis.example.org» \ ~\/ .ssh\/id_ed25519
- Dans ssh et sshd, l'algorithme hybride «sntrup761x25519-sha512@openssh.com» (ECDH/x25519 + NTRU Prime), résistant aux attaques par ordinateurs quantiques, a été ajouté par défaut à la liste KexAlgorithms, qui définit l'ordre de sélection des méthodes d'échange de clés. Dans la version OpenSSH 8.9, cette méthode de négociation a été ajoutée entre les méthodes ECDH et DH, mais elle est prévue pour être utilisée par défaut dans la prochaine version.
- Dans ssh-keygen, ssh et ssh-agent, la gestion des clés des tokens FIDO utilisés pour la vérification de l'appareil a été améliorée, y compris les clés pour l'authentification biométrique.
- Une nouvelle commande « ssh-keygen -Y match-principals » a été ajoutée à ssh-keygen pour vérifier les noms d'utilisateur dans le fichier de liste des noms autorisés.
- Dans ssh-add et ssh-agent, il est désormais possible d'ajouter des clés FIDO protégées par un code PIN dans ssh-agent (la demande de code PIN s'affiche au moment de l'authentification).
- Dans ssh-keygen, il est désormais possible de choisir l'algorithme de hachage (sha512 ou sha256) lors de la génération de la signature.
- Dans ssh et sshd, pour améliorer les performances, les données réseau sont lues directement dans le tampon des paquets entrants, en contournant la mise en mémoire tampon intermédiaire dans la pile. Une mise en mémoire tampon directe des données reçues dans le tampon canal est également mise en œuvre.
- Dans ssh, la directive PubkeyAuthentication a élargi la liste des paramètres pris en charge (yes|no|unbound|host-bound) pour permettre le choix de l'option d'extension du protocole utilisée.
Dans une des prochaines versions, il est prévu de passer par défaut l'outil scp à l'utilisation de SFTP au lieu de l'ancien protocole SCP/RCP. SFTP utilise des méthodes de gestion des noms plus prévisibles et n'utilise pas de traitement glob de motifs dans les noms de fichiers via le shell sur l'autre hôte, ce qui pose des problèmes de sécurité. En particulier, lors de l'utilisation de SCP et RCP, le serveur décide des fichiers et des répertoires à envoyer au client, et le client ne vérifie que la validité des noms d'objets retournés, ce qui, en l'absence de vérifications appropriées côté client, permet de serveur transmettre d'autres noms de fichiers, différents de ceux demandés. Le protocole SFTP ne présente pas ces problèmes, mais ne prend pas en charge le déploiement de chemins spéciaux, tels que « ~/ ». Pour remédier à cette différence, une nouvelle extension du protocole SFTP pour le déploiement des chemins ~/ et ~user/ a été proposée dans la dernière version du serveur SFTP d'OpenSSH.
Source : opennet.ru
