Una vulnerabilidad en OpenSSH y musl libc permite acceder a la cuenta sin contraseña usando una cadena larga

Una vulnerabilidad en la interacción entre OpenSSH y la biblioteca musl libc permite a un atacante acceder a una cuenta con la contraseña deshabilitada enviando por SSH una cadena de entre 257 y 1024 bytes de longitud. Los principales afectados son los servidores Alpine Linux, donde el paquete openssh-server está compilado sin soporte de PAM. Para la explotación basta una sola conexión: el ataque funciona al primer intento. La corrección está disponible en OpenSSH 10.6p2 y en los paquetes actualizados de Alpine para las ramas desde la 3.16 hasta la 3.24. Los administradores de sistemas afectados deben actualizar los paquetes y reiniciar sshd de inmediato o desactivar la autenticación por contraseña.

Detalles técnicos de la vulnerabilidad

A la vulnerabilidad se le ha asignado el identificador CVE-2026-123158 y, según la entrada en GitHub Advisory Database, se ha valorado preliminarmente como de alta gravedad con una puntuación CVSS de 8.1. Hay que tener en cuenta que esta entrada tiene el estado “unreviewed”, y ni OpenSSH ni Alpine han publicado su propia evaluación CVSS.

De acuerdo con el aviso de seguridad de Alpine Linux, para explotar la vulnerabilidad es necesario que se cumplan simultáneamente cuatro condiciones:

• El servidor utiliza el paquete openssh-server sin PAM (o openssh-server-pam con UsePAM no);
• El parámetro PasswordAuthentication está establecido en yes (valor predeterminado en OpenSSH);
• En la cuenta objetivo, el campo de contraseña en /etc/shadow contiene *, es decir, no hay contraseña definida (típico de cuentas que solo usan claves SSH);
• En el sistema existe al menos otra cuenta con un hash de contraseña en formato $5$ (SHA-256 crypt) o $6$ (SHA-512 crypt).

Conviene señalar la discrepancia entre las fuentes respecto a la longitud mínima de la contraseña que desencadena la vulnerabilidad: el aviso de Alpine indica 257 bytes, mientras que la entrada en GitHub Advisory Database habla de 256 bytes. El límite superior en ambos casos es de 1024 bytes, que es la limitación del propio sshd.

Mecanismo de la vulnerabilidad

El problema surge en la intersección de tres componentes: el manejo de errores en la función crypt() de la biblioteca musl, el mecanismo de comprobación de contraseñas en sshd sin PAM y el formato de almacenamiento de los datos de las cuentas.

Cuando sshd funciona sin PAM, él mismo calcula el hash de la contraseña introducida mediante crypt() y compara el resultado con el valor almacenado. Para las cuentas sin contraseña, en el campo del hash se almacena el símbolo *. Como esta cadena es demasiado corta para extraer la sal, sshd toma prestada la sal de otra cuenta que sí tenga un hash real. Este mecanismo de reutilización de sal se introdujo en 2016 para eliminar la vulnerabilidad CVE-2016-6210, que permitía determinar nombres de usuario existentes mediante el tiempo de respuesta del servidor.

El elemento clave es el comportamiento de musl: al procesar hashes $5$ y $6$, la función crypt() se niega a trabajar con contraseñas de más de 256 bytes y devuelve * como indicador de error. Esta decisión se tomó en 2012: en lugar de devolver NULL en caso de error, musl pasó a devolver un “hash no coincidente”, ya que muchos programas no comprobaban el valor NULL. Sin embargo, el valor devuelto * coincide con lo que se almacena en /etc/shadow para las cuentas sin contraseña, y sshd considera la comprobación como correcta.

Es reseñable que los desarrolladores de OpenSSH y musl discrepan en la evaluación de la causa raíz. Según las notas de la versión de OpenSSH 10.6p2, el equipo de OpenSSH considera que el origen del problema es externo a sshd, aunque la explotación puede evitarse de su lado. El desarrollador de musl, Rich Felker, por su parte, señala que el problema está en cómo el programa llamante maneja el valor devuelto por crypt().

Alcance del impacto

Se ven afectadas todas las versiones de Alpine Linux desde la 3.16 hasta la 3.24 y la rama edge, siempre que se dé la configuración descrita. Los sistemas basados en glibc, así como cualquier configuración con PAM habilitado, no son vulnerables.

Merecen especial atención las imágenes en la nube de Alpine basadas en tiny-cloud de las versiones 3.18.11 a 3.24.3. En ellas existe la cuenta alpine con el campo de contraseña * y permiso para ejecutar comandos mediante doas sin contraseña. Estas imágenes son seguras en el primer arranque, pero se vuelven vulnerables en cuanto aparece en el sistema al menos un hash en formato $6$; por ejemplo, después de que el administrador defina una contraseña para el acceso por consola. En este caso, un atacante puede acceder como alpine y obtener privilegios de root a través de doas.

La cuenta root, por defecto, está protegida con el ajuste PermitRootLogin prohibit-password, pero esto no ayuda si la cuenta comprometida tiene capacidad de escalada de privilegios.

En cuanto a otros sistemas basados en musl, el investigador Özgün Kültekin de la empresa Wakefield, que descubrió la vulnerabilidad, menciona OpenWrt, Buildroot y Yocto como plataformas que requieren comprobación. Sin embargo, el radio de impacto práctico es más reducido de lo que podría parecer: el OpenWrt estándar utiliza Dropbear como servidor SSH, según se indica en la documentación de OpenWrt, y Dropbear no es vulnerable. El problema es relevante para OpenWrt solo en caso de instalación manual de OpenSSH por parte del administrador.

Ya hay disponible un PoC público para reproducir la vulnerabilidad, aunque en el momento de la publicación no se habían recibido informes de explotación en ataques reales.

Recomendaciones de mitigación

Según el aviso de Alpine, para eliminar la vulnerabilidad es necesario:

1. Actualizar los paquetes: apk upgrade -U -a
2. Reiniciar sshd: rc-service sshd restart; la actualización del paquete no reinicia automáticamente el proceso sshd en ejecución.

Los paquetes corregidos se incluyen en las versiones de mantenimiento Alpine 3.21.10, 3.22.8, 3.23.8 y 3.24.4. Las ramas 3.16–3.20, ya fuera de soporte regular, también han recibido correcciones.

En compilaciones propias de OpenSSH, se debe actualizar a la versión 10.6p2, que contiene una solución temporal: ahora sshd rechaza la coincidencia si el campo de contraseña almacenado tiene menos de cuatro caracteres.

Si no es posible actualizar de inmediato, es necesario desactivar la autenticación por contraseña:

• Asegurarse de que el acceso por clave SSH funciona y no cerrar la sesión actual hasta verificar la nueva conexión;
• Establecer PasswordAuthentication no en la configuración de sshd;
• Verificar la configuración: sshd -t;
• Reiniciar sshd;
• Comprobar el resultado: sshd -T | grep -i passwordauthentication debe devolver passwordauthentication no.

Para detectar una posible intrusión, el aviso de Alpine recomienda revisar /var/log/messages en busca de entradas Accepted password for correspondientes a cuentas sin contraseña, como alpine, root o cuentas que solo utilizan claves. En las máquinas potencialmente comprometidas también conviene revisar el uso de doas, los usuarios creados recientemente, los archivos y las claves autorizadas. Como se indica en el aviso: «Si no puede descartar que se haya producido un acceso, considere la máquina comprometida».

Los administradores de Alpine Linux con acceso SSH habilitado deben actualizar los paquetes y reiniciar sshd en primer lugar en las instancias en la nube tiny-cloud de las versiones 3.18.11–3.24.3, donde la combinación de la vulnerabilidad con los privilegios de doas proporciona un camino directo para obtener root. En todos los demás sistemas afectados, la prioridad de la actualización depende del cumplimiento de las cuatro condiciones descritas: si al menos una de ellas no se cumple, el sistema no es vulnerable a este ataque.