OpenSSH sobre musl: fallo deja entrar sin contraseña

Un asterisco que significa dos cosas distintas

Una configuración concreta de OpenSSH —compilado contra musl y sin PAM— acepta cualquier contraseña de entre 257 y 1024 caracteres en cuentas cuyo campo de contraseña es un asterisco (*). No es una hipótesis de laboratorio: el autor del análisis publicado en sshhole.com compiló sshd en 12 configuraciones distintas y lanzó unas 17.600 autenticaciones anómalas contra ellas. Once coincidieron. La duodécima dijo que sí a cosas que debía rechazar.

Si tu producto corre sobre Alpine —y una parte enorme de los contenedores y las imágenes cloud lo hacen— esto te toca de cerca. En las imágenes oficiales de Alpine para AWS y Azure, la cuenta por defecto es alpine, tiene doas sin contraseña y su campo en /etc/shadow es *. Es decir: root.

Por qué existe el fallo: el centinela que colisiona

Para entenderlo hay que remontarse a 1980. En el Unix de entonces el hash de la contraseña vivía en /etc/passwd, un archivo que cualquiera podía leer. Bill Joy puso un * en el campo de la cuenta daemon para que nadie pudiera entrar nunca con ella. Un * no es un hash: ninguna contraseña puede producir uno. Unix sigue usando ese truco hoy.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Décadas después el hash se mudó a /etc/shadow con formato $6$abc$k2P9…, donde $6$ indica SHA-512 y abc es la sal. Cuando escribes tu contraseña, sshd la hashea con esa misma sal y compara. Si coincide, entras.

El detalle está en qué hace crypt() cuando no puede hacer su trabajo. La especificación POSIX de 1997 es explícita: devuelve NULL. Pero en agosto de 2012 musl —la libc que usa Alpine— cambió eso con el commit b3c4cc12: en lugar de NULL, crypt() devuelve un solo carácter que nunca puede coincidir con un hash real. Ese carácter es *.

Veinte días después musl sumó SHA-512 crypt con un límite de 256 bytes (KEY_MAX) para evitar ataques de denegación de servicio: una contraseña gigantesca mantiene ocupado al servidor. Si la contraseña supera ese límite, crypt() falla. Y cuando falla, devuelve *.

Ahí está la colisión: el centinela de error de musl es idéntico al centinela de cuenta bloqueada de Unix.

El parche de 2016 que cierra el círculo

Falta una pieza, y viene de un arreglo de seguridad. En 2016 se documentó CVE-2016-6210: preguntar por un usuario inexistente respondía al instante, mientras que un usuario real tardaba unos milisegundos. Bastaba cronometrar para saber qué cuentas existían. La solución fue que sshd, cuando no tiene un hash real que verificar, tome prestada la sal de otra cuenta y hashee igual, solo para gastar el mismo tiempo.

Junta las tres piezas y aparece el fallo: sshd toma la sal de bob, llama a crypt() con tu contraseña de 300 caracteres, musl falla y devuelve *, y sshd compara ese * con el * guardado en el campo de alice. Coinciden. Entras.

Sin PAM de por medio, nadie intercepta ese * antes de que llegue a crypt(). Con PAM, la llamada ni siquiera ocurre. Por eso el problema solo aparece en la combinación musl + sin PAM.

Cómo Alpine terminó con cuentas en asterisco

No es casualidad que las cuentas con * abunden justo en el ecosistema musl. En 2019 se descubrió que las imágenes Docker de Alpine no tenían contraseña de root en absoluto (CVE-2019-5021). Alpine lo arregló bloqueando root con !. El problema: sin PAM, ese ! también mata las claves SSH, y las imágenes cloud se administran con claves. En 2022, con Alpine 3.16, root pasó a *: sigue bloqueado y las claves vuelven a funcionar.

El resto del camino es una cadena de casi-aciertos. En 2013 un desarrollador de Debian pidió a glibc que copiara el * de musl (bug #714219); seis años después Debian migró a libxcrypt, que usa *0, y cerró el reporte. Un carácter de diferencia. En diciembre de 2024 la lista de correo de musl discutió que passwd de busybox se rompe con una contraseña de 257 caracteres: mismo *, mismo límite de 256, y nadie mencionó sshd.

¿Tu infraestructura está afectada?

La lista de condiciones es corta y conviene revisarla hoy:

Tu sshd corre sobre musl (Alpine, OpenWrt, Buildroot, Yocto).
No usa PAM: el paquete openssh-server de Alpine no lo usa por defecto, o alguien puso UsePAM no.
Los logins por contraseña siguen activos, que es el comportamiento por defecto.
Existe una cuenta con * como contraseña: usuarios solo con clave SSH, usuarios de LDAP, root en Alpine.
Y existe otra cuenta con contraseña real, cuya sal sshd pueda tomar prestada.

Si estás en Debian, Ubuntu, Fedora, OpenBSD o cualquier sistema con glibc y PAM, no te afecta. Tampoco Dropbear.

¿Qué significa esto para tu startup?

La lección no es que Alpine sea insegura. Es que un valor centinela reutilizado para dos significados distintos —error y bloqueo— puede convertir un fallo de librería en un bypass de autenticación. Y que el bug pasó años sin que nadie lo reportara, porque cada proyecto asumía que otro lo probaba: OpenSSH testea en OpenBSD y glibc, musl no testea sshd, y la mayoría de las distros pasan por PAM, que nunca llega a llamar a crypt() para una cuenta con *.

Acciones concretas para esta semana:

Parchea. Según el writeup, OpenSSH 10.6p2 corrige el fallo. En Alpine: apk upgrade openssh. Si no puedes actualizar todavía, desactiva los logins por contraseña con PasswordAuthentication no en /etc/ssh/sshd_config.d/ y reinicia el servicio.
Audita tus imágenes base. Si publicas contenedores sobre Alpine, revisa qué cuentas tienen * en /etc/shadow y si alguna tiene privilegios elevados sin contraseña. En las imágenes cloud oficiales de Alpine, esa cuenta es root.
Revisa los logs. El propio análisis da la pista: busca entradas de root@tu-servidor donde una cuenta sin contraseña haya aceptado una contraseña. Si aparece, la intrusión ya ocurrió.
Pasa a autenticación por clave y desactiva contraseñas en todos los servidores expuestos. Es la misma recomendación que sale del escaneo de runZero.

El contexto: SSH sigue siendo el protocolo más expuesto

El hallazgo llega en un momento incómodo para la infraestructura. Según el escaneo de runZero presentado por HD Moore en DEF CON 33 y recogido por NetworkWorld, hay unos 22 millones de direcciones con el puerto 22 abierto, por debajo de los 27 millones de 2024, y en 15,4 millones de ellas se llegó hasta la fase de autenticación SSH.

Lo más llamativo es la adopción de parches: de los cerca de 20 millones de servidores OpenSSH expuestos, menos de 500.000 corren la versión 9.8 o posterior, la que introdujo el rate limiting por defecto. Es menos del 2,5%. En un parque así, un fallo que solo afecta a una combinación concreta de libc y PAM puede pasar años sin detectarse, exactamente como ocurrió aquí.

Y hay un detalle que vale para cualquiera que esté montando agentes de IA: el autor del análisis reconoce que usó enjambres de agentes para compilar y probar las 12 configuraciones. La investigación de seguridad asistida por IA ya está encontrando cosas que los equipos humanos no miran: los detalles aburridos donde sshd habla con la libc, en palabras del propio autor.

Conclusión

El fallo de OpenSSH sobre musl recuerda que la seguridad de tu stack no depende solo de la criptografía, sino de cómo se comportan las capas de abajo cuando algo falla. Un * que significa error en una libc y bloqueado en un archivo de sistema bastó para abrir cuentas.

Si corres Alpine sin PAM, la ventana es de 257 a 1024 caracteres y el parche ya existe. Actualiza, desactiva los logins por contraseña y revisa los logs. Si no corres esa combinación, respira, pero revisa igual cuántos de tus servidores siguen en una versión de OpenSSH con más de un año de antigüedad: el escaneo de runZero sugiere que son la mayoría.