OpenSSH ha publicado la versión 10.6p2 para solucionar una vulnerabilidad crítica que deja entrar en cuentas sin contraseña de algunos servidores basados en Linux con credenciales extremadamente largas (más de 256 caracteres). El fallo afecta a las instalaciones con el paquete estándar openssh-server, compilado sin PAM, y exige que otra cuenta del sistema tenga un hash de contraseña de tipo $5$ o $6$. Alpine Linux ya ha publicado paquetes corregidos desde la versión 3.16, incluidas las ramas sin soporte activo.
El ataque funciona con una sola conexión si el atacante conoce el nombre de una cuenta sin contraseña y envía una cadena de entre 257 y 1.024 caracteres. Por ahora no se han detectado ataques reales, aunque los ajustes por defecto de Alpine dejan expuestos a bastantes servidores en la nube y contenedores.
¿Qué servidores Linux están en riesgo?
El fallo exige cuatro condiciones a la vez: que el servidor ejecute openssh-server sin PAM (o openssh-server-pam con UsePAM no), que PasswordAuthentication esté en yes (el valor por defecto en Alpine Linux y otras distribuciones), que una cuenta tenga el carácter * en el campo de configuración de la contraseña, y que otra cuenta del sistema use un hash que empiece por $5$ o $6$. Basta con que una sola cuenta tenga ese hash para dejar expuestas a todas las que no tienen contraseña.
Entre las cuentas sin contraseña están los usuarios creados solo con clave SSH, los que llegan desde un servicio de directorio a través de musl-nscd, el usuario alpine de las imágenes de nube construidas con tiny-cloud y root, que figura como «root:*» en la imagen base desde Alpine 3.16. Root está protegido por PermitRootLogin prohibit-password, aunque esa barrera no sirve de nada si una cuenta expuesta puede convertirse en root a través de doas.
Las imágenes tiny-cloud de las versiones 3.18.11 a 3.24.3 dan al usuario alpine permiso «doas» (sudo) sin contraseña. Son seguras en el primer arranque, pero basta con que aparezca un hash $6$ en la máquina (por ejemplo, en cuanto el administrador fija una contraseña de consola) para que queden abiertas de par en par. A partir de ese momento, un atacante puede entrar como alpine y usar «doas» para convertirse en root. Muchos despliegues en la nube parecen seguros durante semanas, hasta que un administrador añade esa contraseña de consola o crea un segundo usuario con hash $6$.
Cómo parchear Alpine o cortar las contraseñas si no puedes actualizar ya
El arreglo definitivo pasa por actualizar los paquetes y reiniciar el servicio, porque lo primero no reinicia sshd en marcha. Las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya traen la corrección (igual que la 10.6p2 si compilas OpenSSH por tu cuenta), y las ramas anteriores hasta la 3.16, aunque llevan tiempo sin soporte, también la han recibido:
- Actualizar los paquetes: apk upgrade -U -a
- Reiniciar el servidor: rc-service sshd restart
Damien Miller, del proyecto OpenSSH, pidió actuar sin demora: configura «PasswordAuthentication=no» o deshabilita el servidor SSH para esos equipos inmediatamente. Si no puedes actualizar todavía, vamos a explicarte cómo cortar el acceso por contraseña de forma manual:
- Crea un archivo en /etc/ssh/sshd_config.d (Alpine lo lee desde la 3.19) o cambia cada línea PasswordAuthentication de yes a no en /etc/ssh/sshd_config.
- Valida con sshd -t y reinicia; sshd -T | grep -i passwordauthentication debe devolver passwordauthentication no.
El aviso aconseja revisar /var/log/messages en busca de líneas «Accepted password for» en cuentas que no deberían tenerla: Si no puedes descartar un inicio de sesión, trata la máquina Linux como comprometida.
El problema no es exclusivo de Alpine: afecta a cualquier sistema con la biblioteca musl que ejecute sshd sin PAM. Quedan fuera los sistemas no Linux, las distribuciones con glibc, los contenedores sin sshd y las cuentas bloqueadas con ! en /etc/shadow. Özgün Kültekin, investigador de Wakefield que reportó el fallo, apunta en su análisis técnico que OpenWrt, Buildroot y Yocto también merecen revisión, aunque en OpenWrt el servidor SSH por defecto es Dropbear, que no está afectado. Puedes ver toda la información en la web oficial de SSH Hole.
El equipo de OpenSSH conoció el fallo a principios de esta semana y publicó la corrección enseguida. Miller explicó en el anuncio que mantener embargos largos se ha vuelto peligroso porque ayuda sobre todo a los atacantes: según contó, agentes de IA han llegado a encontrar el mismo tipo de errores por su cuenta, a veces en cuestión de horas. El fallo, de momento, sigue sin un identificador CVE.