Después de tres meses de desarrollo lanzamiento , una implementación abierta de cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP.
En la nueva versión se ha añadido protección contra ataques a scp, permitiendo que el servidor transmita otros nombres de archivos distintos a los solicitados (a diferencia de , el ataque no permite cambiar el directorio o la máscara glob seleccionada por el usuario). Recordemos que en SCP el servidor decide qué archivos y directorios enviar al cliente, mientras que el cliente solo verifica la corrección de los nombres de los objetos devueltos. La naturaleza del problema detectado es que si la llamada del sistema utimes falla, el contenido del archivo se interpreta como metadatos del archivo.
Esta característica, al conectarse a un servidor controlado por un atacante, puede ser utilizada para guardar en el sistema de archivos del usuario otros nombres de archivos y otro contenido al copiar mediante scp en configuraciones que causan fallos en la llamada utimes (por ejemplo, cuando utimes está prohibido por la política de SELinux o un filtro de llamadas al sistema). La probabilidad de ataques reales se evalúa como mínima, ya que en configuraciones típicas la llamada utimes no falla. Además, el ataque no pasa desapercibido: al llamar a scp se muestra un error de transferencia de datos.
Cambios generales:
- En sftp se ha dejado de procesar el argumento "-1" de manera similar a ssh y scp, que antes se aceptaba pero se ignoraba;
- En sshd, al usar IgnoreRhosts ahora se ofrecen tres opciones: "yes" — ignorar rhosts/shosts, "no" — tener en cuenta rhosts/shosts y "shosts-only" — permitir " .shosts ", pero prohibir " .rhosts ";
- En ssh se asegura el manejo de la sustitución %TOKEN en la configuración LocalFoward y RemoteForward, utilizadas para redirigir sockets Unix;
- Se permite cargar claves públicas desde un archivo no cifrado con la clave privada, si falta un archivo separado con la clave pública;
- Al tener libcrypto en el sistema, ssh y sshd ahora utilizan la implementación del algoritmo chacha20 de esta biblioteca, en lugar de la implementación portátil incorporada, que es inferior en rendimiento;
- Se ha implementado la posibilidad de volcar el contenido de la lista binaria de certificados revocados al ejecutar el comando "ssh-keygen -lQf /path";
- En la versión portátil se ha implementado la detección de sistemas en los que las señales con la opción SA_RESTART interrumpen la operación de select;
- Se han resuelto problemas de compilación en sistemas HP/UX y AIX;
- Se resolvieron problemas con la construcción del sandbox de seccomp en algunas configuraciones de Linux;
- Se mejoró la detección de la biblioteca libfido2 y se solucionaron problemas de construcción con la opción «—with-security-key-builtin».
Los desarrolladores de OpenSSH también han advertido una vez más sobre la inminente eliminación de los algoritmos que utilizan hashes SHA-1, debido a en la eficacia de los ataques de colisión con un prefijo específico (el costo de generar una colisión se estima en aproximadamente 45 mil dólares). En una de las próximas versiones, se planea desactivar por defecto la posibilidad de utilizar el algoritmo de firma digital de clave pública «ssh-rsa», mencionado en el RFC original para el protocolo SSH y que sigue siendo ampliamente utilizado en la práctica (para verificar la implementación de ssh-rsa en sus sistemas, se puede intentar conectarse por ssh con la opción «-oHostKeyAlgorithms=-ssh-rsa»).
Para suavizar la transición a nuevos algoritmos en OpenSSH, en una de las siguientes versiones se activará por defecto la configuración UpdateHostKeys, que permitirá a los clientes migrar automáticamente a algoritmos más seguros. Entre los algoritmos recomendados para la migración se mencionan rsa-sha2-256/512 basados en el RFC8332 RSA SHA-2 (soportado desde OpenSSH 7.2 y utilizado por defecto), ssh-ed25519 (soportado desde OpenSSH 6.5) y ecdsa-sha2-nistp256/384/521 basados en el RFC5656 ECDSA (soportado desde OpenSSH 5.7).
A partir del último lanzamiento, «ssh-rsa» y «diffie-hellman-group14-sha1» han sido eliminados de la lista CASignatureAlgorithms, que define los algoritmos permitidos para la firma digital de nuevos certificados, ya que el uso de SHA-1 en certificados implica un riesgo adicional debido a que un atacante tiene un tiempo ilimitado para buscar colisiones para un certificado existente, mientras que el tiempo de ataque a las claves host está limitado por el tiempo de espera de conexión (LoginGraceTime).
Fuente: opennet.ru
