La version OpenSSH 8.3 corrige la vulnérabilité scp

Après trois mois de développement soumis libération OpenSSH 8.3, une implémentation client et serveur ouverte pour travailler via les protocoles SSH 2.0 et SFTP.

La nouvelle version ajoute une protection contre les attaques scp qui permettent au serveur de transmettre d'autres noms de fichiers que ceux demandés (par opposition à vulnérabilité passée, l'attaque ne permet pas de modifier le répertoire ou le masque global sélectionné par l'utilisateur). Rappelez-vous que dans SCP, 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. L'essence 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 de fichier.

Cette fonctionnalité, lors de la connexion à un serveur contrôlé par un attaquant, peut être utilisée pour enregistrer d'autres noms de fichiers et d'autres contenus dans le FS de l'utilisateur lors d'une copie à l'aide de scp dans des configurations qui entraînent un échec lors de l'appel d'utimes (par exemple, lorsque utimes est interdit par la politique SELinux ou le filtre d'appel système) . La probabilité d'attaques réelles est estimée minime, car dans les configurations typiques, l'appel utimes n'échoue pas. De plus, l'attaque ne passe pas inaperçue : lors de l'appel de scp, une erreur de transfert de données s'affiche.

Modifications générales :

  • Dans sftp, le traitement de l'argument « -1 » a été arrêté, comme pour ssh et scp, qui était auparavant accepté mais ignoré ;
  • Dans sshd, lorsque vous utilisez IgnoreRhosts, il y a maintenant trois choix : "oui" - ignorer les rhosts/shosts, "no" - respecter les rhosts/shosts et "shosts-only" - autoriser ".shosts" mais désactiver ".rhosts" ;
  • Ssh prend désormais en charge la substitution %TOKEN dans les paramètres LocalFoward et RemoteForward utilisés pour rediriger les sockets Unix ;
  • Autoriser le chargement de clés publiques à partir d'un fichier non chiffré avec une clé privée s'il n'existe pas de fichier séparé avec la clé publique ;
  • Si libcrypto est disponible dans le système, ssh et sshd utilisent désormais l'implémentation de l'algorithme chacha20 de cette bibliothèque, au lieu de l'implémentation portable intégrée, qui est en retard en termes de performances ;
  • Implémentation de la possibilité de vider le contenu d'une liste binaire de certificats révoqués lors de l'exécution de la commande « ssh-keygen -lQf /path » ;
  • La version portable implémente des définitions de systèmes dans lesquels les signaux avec l'option SA_RESTART interrompent l'opération de sélection ;
  • Résolution de problèmes d'assemblage sur les systèmes HP/UX et AIX ;
  • Correction de problèmes lors de la création du sandbox seccomp sur certaines configurations Linux ;
  • Amélioration de la détection de la bibliothèque libfido2 et résolution des problèmes de build avec l'option "--with-security-key-builtin".

Les développeurs d'OpenSSH ont également une fois de plus mis en garde contre la décomposition imminente des algorithmes utilisant les hachages SHA-1 en raison de promotion l'efficacité des attaques par collision avec un préfixe donné (le coût de sélection d'une collision est estimé à environ 45 mille dollars). Dans l'une des prochaines versions, ils prévoient de désactiver par défaut la possibilité d'utiliser l'algorithme de signature numérique à clé publique « ssh-rsa », qui est mentionné dans la RFC originale pour le protocole SSH et reste répandu dans la pratique (pour tester 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 de nouveaux algorithmes dans OpenSSH, dans une prochaine version, le paramètre UpdateHostKeys sera activé par défaut, ce qui migrera automatiquement les clients vers des algorithmes plus fiables. Les algorithmes recommandés pour la migration incluent rsa-sha2-256/512 basé sur RFC8332 RSA SHA-2 (pris en charge depuis OpenSSH 7.2 et utilisé par défaut), ssh-ed25519 (pris en charge depuis OpenSSH 6.5) et ecdsa-sha2-nistp256/384/521 basé sur sur RFC5656 ECDSA (pris en charge depuis OpenSSH 5.7).

Depuis 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 à signer numériquement de nouveaux certificats, car l'utilisation de SHA-1 dans les certificats présente un risque supplémentaire. de ce fait, l'attaquant dispose d'un temps illimité pour rechercher une collision pour un certificat existant, tandis que le temps d'attaque sur les clés de l'hôte est limité par le délai d'expiration de la connexion (LoginGraceTime).

Source: opennet.ru

Ajouter un commentaire