- OpenSSH 10.6p2 corrige un fallo que permite entrar sin contraseña en servidores Linux con Alpine, musl y sin PAM.
- El ataque exige una cuenta con asterisco en /etc/shadow y otra con hash $5$ o $6$, además de una contraseña de 257 a 1.024 caracteres.
- Alpine ha publicado paquetes corregidos; hay que actualizar y reiniciar sshd, o desactivar PasswordAuthentication si no se puede.
- Damien Miller, de OpenSSH, pide actuar «inmediatamente» con «PasswordAuthentication=no» o deshabilitando el servidor SSH.
OpenSSH ha publicado la versión 10.6p2 para tapar una vulnerabilidad que permite entrar en determinadas cuentas de servidores Linux sin conocer la contraseña. El fallo afecta a configuraciones de Alpine Linux que combinan OpenSSH con la biblioteca musl y funcionan sin PAM. Las correcciones llegaron el 5 de noviembre y el proyecto pide aplicarlas cuanto antes.
Damien Miller, del equipo de OpenSSH, ha sido claro: hay que desactivar el acceso por contraseña o apagar el servidor SSH en los equipos expuestos. La advertencia no es menor porque el ataque puede completarse con una sola conexión si se cumplen las condiciones. No hace falta adivinar ni romper una contraseña válida.
¿Qué condiciones deben darse para que un servidor Linux esté expuesto?
El fallo no alcanza a cualquier Linux. Necesita que openssh-server funcione sin PAM, que la autenticación por contraseña esté activada y que coincidan dos circunstancias en las cuentas del sistema. La primera es una cuenta con un asterisco en el campo de contraseña de /etc/shadow. La segunda, otra cuenta local con un hash SHA-256 o SHA-512, reconocible por empezar por $5$ o $6$.
Si se dan esas condiciones, el atacante solo tiene que conocer el nombre de la cuenta sin contraseña y enviar una cadena de entre 257 y 1.024 caracteres. La función de musl devuelve un asterisco al procesar esa contraseña larga, y sshd lo interpreta como una coincidencia con el asterisco de la cuenta protegida. El resultado es un acceso que debería estar bloqueado.
¿A quién afecta y qué sistemas están en riesgo?
El escenario más directo es Alpine Linux, pero no es el único. Cualquier sistema basado en musl que ejecute sshd sin PAM puede reunir las condiciones. Quedan fuera las distribuciones con glibc, los sistemas que utilizan PAM para gestionar la autenticación y aquellos que tienen desactivado el acceso por contraseña. Los contenedores y las imágenes de nube son los entornos donde el riesgo se multiplica.
Alpine ha señalado que algunas imágenes oficiales de nube permiten al usuario alpine ejecutar comandos como administrador mediante doas sin contraseña. Esas imágenes son seguras en el primer arranque, pero pueden quedar abiertas si después se añade una cuenta con un hash compatible. La combinación de una cuenta sin contraseña y otra con hash válido es la que abre la puerta.
Cómo parchear Alpine y qué hacer si no puedes actualizar
La solución definitiva pasa por actualizar los paquetes y reiniciar el servicio SSH, porque la actualización por sí sola no reinicia sshd en marcha. Alpine ha publicado paquetes corregidos para varias ramas, incluidas algunas que ya no tienen soporte activo. OpenSSH también ha lanzado la versión 10.6p2 para quienes compilan el código por su cuenta.
- Actualizar los paquetes en Alpine con apk upgrade -U -a.
- Reiniciar el servidor SSH con rc-service sshd restart.
- Si no puedes actualizar, poner PasswordAuthentication no en la configuración de sshd y reiniciar el servicio.
- Revisar /var/log/messages en busca de líneas «Accepted password for» en cuentas que no deberían tener acceso.
Miller recomienda no esperar: «Configura PasswordAuthentication=no o deshabilita el servidor SSH para esos equipos inmediatamente». Antes de cerrar el acceso por contraseña conviene comprobar que las claves SSH funcionan, validar la configuración con sshd -t y reiniciar. Si no se puede descartar un inicio de sesión, el consejo es tratar la máquina como comprometida.
¿Qué se sabe del origen del fallo y de sus responsables?
El fallo fue descubierto por el investigador Özgün Kültekin, de Wakefield, y comunicado a los proyectos afectados. OpenSSH y Alpine publicaron sus respectivas correcciones el 5 de noviembre. La coordinación fue rápida, pero la ventana de exposición depende de cuándo cada administrador actualice y reinicie sus servidores.
La vulnerabilidad afecta a una combinación muy concreta de piezas: OpenSSH, musl y la ausencia de PAM. Esa mezcla es habitual en Alpine Linux, una distribución ligera muy usada en contenedores y servicios en la nube. También puede aparecer en otras instalaciones basadas en musl, aunque no todos los sistemas con musl están expuestos: depende de que sshd funcione sin PAM y de la configuración de las cuentas.
El aviso llega en un momento de presión para los administradores de sistemas, que deben revisar inventarios y aplicar parches en entornos dispersos. La recomendación común es actualizar, reiniciar sshd y verificar los registros; si no hay margen para actualizar, cerrar el acceso por contraseña es la medida más segura. La clave está en no dejar la configuración por defecto de Alpine expuesta más tiempo del necesario.
Índice