OpenSSH 10.6 añade firmas poscuánticas y acelera versiones
OpenSSH 10.6 se publicó el 6 de octubre. Activa un algoritmo híbrido de firma poscuántica, debilita la opción Compression para bloquear un ataque entre canales y corrige otros fallos de seguridad. Además, los responsables del proyecto anuncian que, de momento, publicarán versiones con más frecuencia.
OpenSSH es el conjunto de herramientas de código abierto que está detrás de la mayoría de los inicios de sesión remotos en Linux, BSD y muchos otros sistemas. Incluye el servidor sshd, el cliente ssh y utilidades como sftp y ssh-keygen. Los administradores que usen el servidor o el cliente deben contar con actualizaciones más seguidas de lo habitual.
Los informes de fallos asistidos por IA cambian el ritmo
El equipo explicó que el nuevo calendario busca que las correcciones lleguen antes a los usuarios. El proyecto ha recibido una gran cantidad de informes de seguridad. Muchos de esos fallos los encontraron modelos de IA o se descubrieron con ayuda de la IA. En varios casos, otro investigador dio después con el mismo fallo por su cuenta.
Los responsables sacan una conclusión clara. Los atacantes que no comunican los fallos a los proyectos de código abierto, escribieron, "probablemente también sean capaces de descubrir estos fallos".
Esto encaja con una tendencia más amplia. Otros programas de código abierto se han visto desbordados por la misma avalancha, y Google suspendió hace poco su programa de recompensas OSS por los informes generados por IA.
Compression se queda sin diccionario
Tanto ssh como sshd desactivan ahora el codificador de diccionario LZ77, así que la opción Compression es menos eficaz que antes. El cambio responde a una investigación de Fabian Bäumer y Marcus Brinkmann. Ambos describieron un ataque en el que alguien que controla la entrada de un canal puede recuperar secretos que viajan por otro.
El problema está en cómo funciona la compresión dentro de una sesión. Todos los canales comparten un único diccionario de compresión. Cuando se repiten cadenas entre canales, cambia la longitud del texto cifrado, y esa diferencia filtra información. Los responsables recomiendan comprimir los datos en la capa de aplicación. Según ellos, suele ser más eficaz y no se ve afectado por el ataque.
Rechazo a nombres de usuario con $ o \
El cliente ssh rechaza ahora los nombres de usuario indicados en la línea de comandos si contienen un signo de dólar o una barra invertida. De lo contrario, un nombre procedente de una fuente no fiable podría servir para inyectar código en un contexto de shell a través de las opciones ProxyCommand o Match exec.
Los nombres de usuario definidos con la directiva User en los archivos de configuración no se ven afectados. Los responsables advierten de que una medida de mitigación como esta no puede ser absoluta.
Otras correcciones
También se han resuelto varios problemas menores:
- sshd guarda ahora las credenciales GSSAPI solo cuando la autenticación tiene éxito. Antes, las credenciales de un intento fallido podían quedarse almacenadas y quedar expuestas tras un inicio de sesión correcto posterior.
- sftp comprueba con más rigor las rutas que devuelve el servidor. Así se cierran casos en los que un servidor malicioso podía desviar una copia recursiva fuera del directorio de destino previsto.
- ssh-keygen gestionaba mal el horario de verano. Los certificados podían llevar fechas de caducidad desfasadas hasta una hora, o hasta dos horas en la zona horaria Antarctica/Troll.
En QNX 6, SCO OpenServer 5 y las compilaciones sin paso de descriptores de archivo, el proceso posterior a la autenticación mantiene los privilegios de root. GatewayPorts y StreamLocalForwarding quedan ahora desactivados en esas plataformas. El equipo avisó de que dejará de darles soporte en el futuro si no encuentra una alternativa.
Hay que sustituir las claves poscuánticas
La versión activa el algoritmo híbrido de firma poscuántica ssh-mldsa44-ed25519, que combina ML-DSA-44 con el esquema clásico Ed25519. Quien haya generado claves con el soporte experimental anterior debe regenerarlas o eliminarlas.
Nuestro análisis
Lo más revelador de esta versión no es una corrección concreta, sino la explicación que hay detrás del nuevo calendario. OpenSSH es uno de los códigos más revisados del mundo del código abierto. Cuando sus responsables dicen que las herramientas de IA sacan fallos a la luz tan deprisa que investigadores independientes acaban coincidiendo en los mismos hallazgos, todo apunta a que el margen entre el descubrimiento y la explotación se está acortando. Ya informamos de que las divulgaciones de vulnerabilidades se duplican a medida que la IA acelera la explotación, y un fallo de Rejetto HFS descubierto por IA acabó explotándose activamente.
Para los defensores, la lección práctica es tratar OpenSSH como un navegador: parchear rápido y a menudo. Los equipos que dependían de la compresión de SSH deberían comprobar el impacto, y quien haya probado las claves poscuánticas experimentales debería rotarlas ya. Habrá que ver si otros proyectos clave de infraestructura adoptan ritmos de publicación parecidos y si este ritmo se mantiene o se calma cuando se despache la acumulación de informes.
