Después de tres meses de desarrollo relizar , una implementación abierta de cliente y servidor para trabajar a través de los protocolos SSH 2.0 y SFTP.
La nueva versión agrega protección contra ataques scp que permiten al servidor pasar nombres de archivos distintos a los solicitados (a diferencia de , el ataque no permite cambiar el directorio seleccionado por el usuario ni la máscara global). Recuerde que en SCP, el servidor decide qué archivos y directorios enviar al cliente, y el cliente solo verifica la exactitud de los nombres de los objetos devueltos. La esencia del problema identificado es que si falla la llamada al sistema utimes, el contenido del archivo se interpreta como metadatos del archivo.
Esta característica, cuando se conecta a un servidor controlado por un atacante, se puede usar para guardar otros nombres de archivos y otro contenido en el FS del usuario al copiar usando scp en configuraciones que conducen a fallas al llamar a utimes (por ejemplo, cuando utimes está prohibido por la política SELinux o el filtro de llamadas al sistema). Se estima que la probabilidad de ataques reales es mínima, ya que en configuraciones típicas la llamada a utimes no falla. Además, el ataque no pasa desapercibido: al llamar a scp, se muestra un error en la transferencia de datos.
Cambios generales:
- En sftp, se detuvo el procesamiento del argumento “-1”, similar a ssh y scp, que anteriormente se aceptaba pero se ignoraba;
- En sshd, cuando se usa IgnoreRhosts, ahora hay tres opciones: "sí" - ignorar rhosts/shosts, "no" - respetar rhosts/shosts y "solo shosts" - permitir ".shosts" pero no permitir ".rhosts";
- Ssh ahora admite la sustitución de %TOKEN en las configuraciones LocalFoward y RemoteForward utilizadas para redirigir sockets Unix;
- Permitir cargar claves públicas desde un archivo no cifrado con una clave privada si no hay un archivo separado con la clave pública;
- Si libcrypto está disponible 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 se queda atrás en rendimiento;
- Se implementó la capacidad de volcar el contenido de una lista binaria de certificados revocados al ejecutar el comando “ssh-keygen -lQf /path”;
- La versión portátil implementa definiciones de sistemas en los que las señales con la opción SA_RESTART interrumpen la operación de select;
- Resueltos problemas de montaje en sistemas HP/UX y AIX;
- Se solucionaron problemas con la creación de seccomp sandbox en algunas configuraciones de Linux;
- Se mejoró la detección de la biblioteca libfido2 y se resolvieron los problemas de compilación con la opción "--with-security-key-builtin".
Los desarrolladores de OpenSSH también advirtieron una vez más sobre la inminente descomposición de los algoritmos que utilizan hashes SHA-1 debido a la efectividad de los ataques de colisión con un prefijo determinado (el costo de seleccionar una colisión se estima en aproximadamente 45 mil dólares). En una de las próximas versiones, planean desactivar de forma predeterminada la capacidad de utilizar el algoritmo de firma digital de clave pública "ssh-rsa", que se menciona en el RFC original para el protocolo SSH y sigue estando muy extendido en la práctica (para probar el uso). de ssh-rsa en sus sistemas, puede intentar conectarse vía ssh con la opción “-oHostKeyAlgorithms=-ssh-rsa”).
Para facilitar la transición a nuevos algoritmos en OpenSSH, en una versión futura, la configuración UpdateHostKeys estará habilitada de forma predeterminada, lo que migrará automáticamente a los clientes a algoritmos más confiables. Los algoritmos recomendados para la migración incluyen rsa-sha2-256/512 basado en RFC8332 RSA SHA-2 (compatible desde OpenSSH 7.2 y utilizado de forma predeterminada), ssh-ed25519 (compatible desde OpenSSH 6.5) y basado en ecdsa-sha2-nistp256/384/521 en RFC5656 ECDSA (compatible desde OpenSSH 5.7).
A partir de la última versión, "ssh-rsa" y "diffie-hellman-group14-sha1" se eliminaron de la lista CASignatureAlgorithms que define los algoritmos permitidos para firmar digitalmente nuevos certificados, ya que el uso de SHA-1 en certificados plantea un riesgo adicional. debido a esto, el atacante tiene tiempo ilimitado para buscar una colisión para un certificado existente, mientras que el tiempo de ataque a las claves del host está limitado por el tiempo de espera de la conexión (LoginGraceTime).
Fuente: opennet.ru