Publication de OpenSSH 8.3 avec correction de vulnérabilité dans scp

Après trois mois de développement présenté la sortie OpenSSH 8.3, une mise en œuvre ouverte du client et du serveur pour travailler avec les protocoles SSH 2.0 et SFTP.

La nouvelle version ajoute une protection contre les attaques sur scp, permettant au serveur de transmettre d'autres noms de fichiers, différents de ceux demandés (contrairement à la vulnérabilité précédente, l'attaque ne permet pas de changer le répertoire sélectionné par l'utilisateur ou le masque glob). Rappelons que dans SCP, le serveur décide quels fichiers et répertoires envoyer au client, tandis que le client ne fait que vérifier l'exactitude des noms d'objets retournés. La nature du problème identifié est que si l'appel système utimes échoue, le contenu du fichier est interprété comme des métadonnées du fichier.

Cette caractéristique, lors de la connexion à un serveur contrôlé par un attaquant, peut être exploitée pour enregistrer dans le système de fichiers de l'utilisateur d'autres noms de fichiers et d'autres contenus lors de la copie à l'aide de scp dans des configurations entraînant un échec lors de l'appel de utimes (par exemple, en raison de la politique SELinux ou d'un filtre d'appels système interdisant utimes). La probabilité d'attaques réelles est évaluée comme minimale, car dans les configurations typiques l'appel de utimes ne se termine pas par un échec. De plus, l'attaque ne passe pas inaperçue : lors de l'appel scp, une erreur de transmission de données s'affiche.

Modifications générales :

• Dans sftp, le traitement de l'argument «-1» a été arrêté, semblable à ssh et scp, qui était auparavant accepté mais ignoré ;
• Dans sshd, lors de l'utilisation de IgnoreRhosts, trois options sont désormais proposées : «yes» — ignorer rhosts/shosts, «no» — prendre en compte rhosts/shosts et «shosts-only» — autoriser «.shosts», mais interdire «.rhosts» ;
• Dans ssh, la substitution %TOKEN est maintenant prise en charge dans les paramètres LocalFoward et RemoteForward, utilisés pour le redirection des sockets Unix ;
• Le chargement de clés ouvertes à partir d'un fichier non chiffré avec la clé privée est autorisé, en l'absence d'un fichier séparé avec la clé ouverte ;
• Si libcrypto est présent dans le système, ssh et sshd utilisent maintenant l'implémentation de l'algorithme chacha20 à partir de cette bibliothèque, au lieu de l'implémentation portable intégrée, qui est inférieure en performance ;
• Il est possible de faire un dump du contenu de la liste binaire des certificats révoqués lors de l'exécution de la commande «ssh-keygen -lQf /path» ;
• Dans la version portable, il a été implémenté la détection des systèmes dans lesquels les signaux avec l'option SA_RESTART interrompent le fonctionnement de select ;
• Des problèmes de compilation sous les systèmes HP/UX et AIX ont été résolus ;
• Des problèmes de compilation du sandbox seccomp ont été résolus dans certaines configurations Linux ;
• La détection de la bibliothèque libfido2 a été améliorée et des problèmes de compilation avec l'option « —with-security-key-builtin » ont été résolus.

Les développeurs d'OpenSSH ont à nouveau averti sur le prochain passage des algorithmes utilisant des hachages SHA-1 au statut obsolète, en raison de l'augmentation de l'efficacité des attaques par collision avec un préfixe donné (le coût de la recherche d'une collision est évalué à environ 45 000 dollars). Dans l'une des prochaines versions, il est prévu de désactiver par défaut la possibilité d'utiliser l'algorithme de signature numérique à clé publique « ssh-rsa », qui est mentionné dans l'ancienne RFC pour le protocole SSH et reste largement utilisé dans la pratique (pour vérifier l'utilisation de ssh-rsa dans vos systèmes, vous pouvez essayer de vous connecter via ssh avec l'option « -oHostKeyAlgorithms=-ssh-rsa »).

Pour faciliter la transition vers les nouveaux algorithmes dans OpenSSH, l'une des prochaines versions inclura par défaut la configuration UpdateHostKeys, qui permettra de transférer automatiquement les clients vers des algorithmes plus fiables. Parmi les algorithmes recommandés pour la migration figurent rsa-sha2-256/512 basé sur la RFC8332 RSA SHA-2 (soutenu depuis OpenSSH 7.2 et utilisé par défaut), ssh-ed25519 (soutenu depuis OpenSSH 6.5) et ecdsa-sha2-nistp256/384/521 basé sur la RFC5656 ECDSA (soutenu depuis OpenSSH 5.7).

À partir de la dernière version, « ssh-rsa » et « diffie-hellman-group14-sha1 » ont été supprimés de la liste CASignatureAlgorithms, qui définit les algorithmes autorisés pour la signature numérique de nouveaux certificats, car l'utilisation de SHA-1 dans les certificats comporte un risque supplémentaire, étant donné qu'un attaquant a un temps illimité pour rechercher une collision pour un certificat existant, tandis que le temps d'attaque sur les clés d'hôte est limité par le délai de connexion (LoginGraceTime).

Source : opennet.ru