Après six mois de développement, la sortie d'OpenSSH 8.9, une implémentation client et serveur ouverte permettant de travailler sur les protocoles SSH 2.0 et SFTP, a été présentée. La nouvelle version de sshd corrige une vulnérabilité qui pourrait potentiellement permettre un accès non authentifié. Le problème est dû à un dépassement d'entier dans le code d'authentification, mais ne peut être exploité qu'en combinaison avec d'autres erreurs logiques dans le code.
Dans sa forme actuelle, la vulnérabilité ne peut pas être exploitée lorsque le mode de séparation des privilèges est activé, car sa manifestation est bloquée par des vérifications distinctes effectuées dans le code de suivi de séparation des privilèges. Le mode de séparation des privilèges est activé par défaut depuis 2002 depuis 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 par compilation avec les indicateurs de protection contre le dépassement d'entier activés.
Autres changements :
- La version portable d'OpenSSH dans sshd a supprimé la prise en charge native du hachage des mots de passe à l'aide de l'algorithme MD5 (permettant de revenir avec des bibliothèques externes telles que libxcrypt).
- ssh, sshd, ssh-add et ssh-agent implémentent un sous-système pour restreindre le transfert et l'utilisation des clés ajoutées à ssh-agent. Le sous-système vous permet de définir des règles qui déterminent comment et où les clés peuvent être utilisées dans ssh-agent. Par exemple, pour ajouter une clé qui ne peut être utilisée que pour authentifier tout utilisateur se connectant à l'hôte scylla.example.org, l'utilisateur perseus à l'hôte cetus.example.org et l'utilisateur medea à l'hôte charybdis.example.org. avec redirection via un hôte intermédiaire scylla.example.org, vous pouvez utiliser la commande suivante : $ ssh-add -h "[email protected]" \ -h "scylla.exemple.org" \ -h "scylla.exemple.org>[email protected]\ ~/.ssh/id_ed25519
- Dans ssh et sshd, un algorithme hybride a été ajouté par défaut à la liste KexAlgorithms, qui détermine l'ordre dans lequel les méthodes d'échange de clés sont sélectionnées.[email protected]"(ECDH/x25519 + NTRU Prime), résistant à la sélection sur les ordinateurs quantiques. Dans OpenSSH 8.9, cette méthode de négociation a été ajoutée entre les méthodes ECDH et DH, mais il est prévu qu'elle soit activée par défaut dans la prochaine version.
- ssh-keygen, ssh et ssh-agent ont amélioré la gestion des clés de jeton FIDO utilisées pour la vérification des appareils, y compris les clés pour l'authentification biométrique.
- Ajout de la commande "ssh-keygen -Y match-principals" à ssh-keygen pour vérifier les noms d'utilisateur par rapport au fichier de liste de noms autorisés.
- ssh-add et ssh-agent offrent la possibilité d'ajouter des clés FIDO protégées par un code PIN à ssh-agent (la demande de code PIN est affichée au moment de l'authentification).
- ssh-keygen permet le choix de l'algorithme de hachage (sha512 ou sha256) lors de la génération de 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 sur la pile. Le placement direct des données reçues dans un tampon de canal est mis en œuvre de la même manière.
- Dans ssh, la directive PubkeyAuthentication a élargi la liste des paramètres pris en charge (oui|non|non lié|lié à l'hôte) pour offrir la possibilité de sélectionner l'option d'extension de protocole à utiliser.
Dans une prochaine version, nous prévoyons de modifier la valeur par défaut de l'utilitaire scp pour utiliser SFTP au lieu du protocole SCP/RCP existant. SFTP utilise des méthodes de gestion des noms plus prévisibles et n'utilise pas le traitement shell des modèles globaux dans les noms de fichiers du côté de l'autre hôte, ce qui crée des problèmes de sécurité. En particulier, lors de l'utilisation de SCP et RCP, le serveur décide quels fichiers et répertoires envoyer au client, et le client vérifie uniquement l'exactitude des noms d'objet renvoyés, ce qui, en l'absence de vérifications appropriées du côté client, permet le serveur pour transférer d'autres noms de fichiers différents de ceux demandés. Le protocole SFTP n'a pas ces problèmes, mais ne prend pas en charge l'extension de chemins spéciaux tels que « ~/ ». Pour remédier à cette différence, la version précédente d'OpenSSH a introduit une nouvelle extension du protocole SFTP aux chemins ~/ et ~user/ dans l'implémentation du serveur SFTP.
Source: opennet.ru