Après six mois de développement La sortie d'OpenSSH 8.9 annoncée, dans laquelle corriger la vulnérabilité dans sshd qui pourrait potentiellement autoriser l'accès sans authentification. Le problème est causé par un débordement d'entier dans le code d'authentification, mais l'exploitation n'est possible 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 la division des privilèges est activée, car sa manifestation est bloquée par des vérifications séparées effectuées sur le code de suivi de la répartition des privilèges.
Le mode de privilège partagé a été activé par défaut en 2002 à partir d'OpenSSH 3.2.2 et est requis depuis la version 2017 d'OpenSSH 7.5. De plus, dans les versions portables d'OpenSSH depuis la version 6.5 (2014), la vulnérabilité est bloquée en compilant avec l'inclusion de drapeaux pour se protéger contre les débordements d'entiers.
Principales nouveautés d'OpenSSH 8.9
Dans cette nouvelle version qui est présentée, nous pouvons constater que lLa version portable d'OpenSSH supprime le support sshd intégré pour le hachage de mot de passe à l'aide de l'algorithme MD5 (le lien vers des bibliothèques externes comme libxcrypt est autorisé)
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 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 s'authentifier lorsqu'un utilisateur se connecte à l'hôte scylla.example.org, l'utilisateur perseus se connecte à l'hôte cetus.example.org et l'utilisateur medea se connecte à l'hôte charybdis.example .org host, redirection via un hôte intermédiaire scylla.example.org.
En ssh et sshd, la liste des KexAlgorithms, qui détermine l'ordre dans lequel les méthodes d'échange de clés sont sélectionnées, a ajouté par défaut l'algorithme hybride « sntrup761x25519-sha512@openssh.com» (ECDH/x25519 + NTRU Prime), qui résiste à la sélection dans 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 de l'activer 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é pour la vérification de l'appareil, y compris les clés pour l'authentification biométrique.
Parmi les autres changements qui ressortent de cette nouvelle version:
- Ajout de la commande "ssh-keygen -Y match-principals" à ssh-keygen pour vérifier les noms d'utilisateur dans un fichier avec une 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 (une invite de code PIN s'affiche au moment de l'authentification).
- ssh-keygen vous permet de choisir l'algorithme de hachage (sha512 ou sha256) lors de la signature.
Pour améliorer les performances, ssh et sshd lisent les données réseau directement dans le tampon de paquets entrant, en contournant le tampon intermédiaire de la pile. Le placement direct des données reçues dans le tampon de canal est mis en œuvre d'une manière similaire. - Dans ssh, la directive PubkeyAuthentication a étendu la liste des paramètres pris en charge (yes|no|unbound|host-bound) pour permettre de sélectionner l'extension de protocole à utiliser.
Dans une future version, il est prévu de modifier l'utilitaire scp utiliser par défaut 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 le traitement shell des modèles glob sur les noms de fichiers de l'autre côté de l'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 ne vérifie que l'exactitude des noms des objets renvoyés, ce qui, en l'absence de vérifications appropriées par le client, permet que le serveur transfère d'autres noms de fichiers différents de ceux demandés. Le protocole SFTP n'a pas ces problèmes, mais il ne prend pas en charge l'extension de chemins spéciaux comme "~/
Enfin si vous souhaitez en savoir plus à propos de cette nouvelle version, vous pouvez vérifier les détails en allant sur le lien suivant.
Comment installer OpenSSH 8.9 sur Linux?
Pour ceux qui souhaitent pouvoir installer cette nouvelle version d'OpenSSH sur leurs systèmes, pour l'instant ils peuvent le faire télécharger le code source de ceci et effectuer la compilation sur leurs ordinateurs.
En effet, la nouvelle version n'a pas encore été incluse dans les référentiels des principales distributions Linux. Pour obtenir le code source, vous pouvez le faire à partir du lien ci-dessous.
Terminé le téléchargement, maintenant, nous allons décompresser le package avec la commande suivante:
tar -xvf openssh-8.9.tar.gz
Nous entrons dans le répertoire créé:
cd openssh-8.9
Y nous pouvons compiler avec les commandes suivantes:
./configure --prefix=/opt --sysconfdir=/etc/ssh make make install