Según las normas básicas de seguridad, una cuenta bloqueada por el sistema operativo no puede utilizarse bajo ninguna circunstancia. Cualquier contraseña ingresada debería ser rechazada de inmediato. Sin embargo, el 5 de noviembre de 2026, un aviso de seguridad publicado por la distribución ligera Alpine Linux rompió por completo esta certeza.
A un atacante le bastaba con ingresar una contraseña de más de 256 bytes para que una cuenta de administrador bloqueada le abriera las puertas. Todo esto sin corromper la memoria ni realizar ataques de fuerza bruta contra hashes. Tras cotejar la contraseña con el indicador de bloqueo, el propio sistema defensivo autorizó el acceso voluntariamente.
Esta anomalía se produjo por la colisión imprevista entre tres controles de seguridad independientes. Cuando un código de error que significa “cálculo fallido” y un estado de cuenta que representa “acceso prohibido” comparten el mismo carácter, la lógica de autenticación se derrumba en su punto de intersección.
Tres mecanismos de defensa coordinados que cedieron ante 257 caracteres
En el archivo de contraseñas de Unix /etc/shadow, el asterisco * ha representado cuentas bloqueadas durante décadas. Cuando el campo de contraseña contiene un único asterisco, el sistema considera desactivada la autenticación por contraseña. El hash generado por una contraseña válida consta de decenas de caracteres, por lo que una coincidencia con un solo asterisco resulta imposible.
Para neutralizar ataques de temporización destinados a descubrir nombres de usuario válidos, los ingenieros de OpenSSH implementaron una protección específica. Si una cuenta carece de contraseña válida, el servicio no responde con un error inmediato. En su lugar, toma prestado el salt de otra cuenta legítima del sistema y realiza un cálculo simulado de duración similar. De este modo, los tiempos de respuesta se igualan independientemente de si la cuenta existe o no.
Por su parte, la biblioteca ligera musl de C impone sus propios límites de protección. Con el fin de evitar que entradas maliciosas desborden la memoria, la función crypt() de musl establece una longitud máxima estricta. Si la contraseña supera los 256 bytes, la función interrumpe el cálculo de inmediato y devuelve un puntero a un asterisco estático * como indicador de error.
Analizados por separado, cada uno de estos tres mecanismos responde a una filosofía de diseño rigurosa. Sin embargo, al operar dentro del mismo entorno, abrieron inadvertidamente una vía de ataque directa.
El atacante solo requería cuatro condiciones:
- Tener conectividad al puerto SSH del servidor objetivo;
- Localizar una cuenta cuyo campo de contraseña en shadow contenga
*(como la cuenta root predeterminada en Alpine desde la versión 3.16); - Contar con al menos otra cuenta legítima en el sistema con un hash en formato
$5$o$6$; - Enviar una contraseña extralarga de entre 257 y 1024 bytes.
Al cumplirse estas cuatro premisas, OpenSSH recibe la contraseña extralarga y utiliza el salt prestado para calcular el hash simulado. La biblioteca musl interrumpe el proceso por exceso de longitud y devuelve el carácter de error *. A continuación, OpenSSH compara este resultado con el campo de contraseña del archivo shadow: ambos lados contienen un único asterisco. La comprobación concluye con éxito y la cuenta bloqueada permite el acceso.
Figura: Aviso oficial de seguridad de Alpine Linux que detalla la evasión de autenticación sin PAM. Fuente: alpinelinux.org.
Dos significados para un mismo asterisco: Cuenta bloqueada y error de cálculo
El origen del problema radica en el conflicto semántico que distintas capas de software atribuyeron a un mismo símbolo. El software superior interpretó el asterisco como un cerrojo infranqueable, mientras que la biblioteca subyacente lo utilizó como bandera blanca de error.
En las implementaciones tradicionales de Unix, las funciones de cifrado solían devolver un puntero nulo ante entradas no válidas. El código llamador comprobaba si el puntero era nulo para discernir entre éxito y fallo. Sin embargo, los punteros nulos provocaban caídas por desreferencia en aplicaciones heredadas. musl optó por ceñirse a un estándar que devuelve un puntero a una cadena estática con * en caso de error.
Este diseño asumía que quien invocaba la función sabría que un asterisco representaba un hash inválido. En condiciones habituales, esta premisa se cumplía sin problemas: aunque la entrada generase un asterisco, las cuentas reales contenían hashes completos con los que era imposible coincidir.
Fue la lógica de salt simulado de OpenSSH la que introdujo el eslabón fatal. En entornos mínimos sin PAM, el propio proceso sshd valida las contraseñas directamente. Para no revelar información mediante diferencias en el tiempo de respuesta, OpenSSH decidió ejecutar el cálculo de cifrado incluso sobre cuentas bloqueadas.
Esto condujo a un callejón sin salida. OpenSSH creyó estar validando una contraseña suministrada, cuando en realidad la biblioteca había cancelado el procesamiento. Esa discrepancia de interpretación transformó una marca de bloqueo en una llave maestra.
El peligro oculto en imágenes de nube: Un usuario adicional activa la trampa
Tras hacerse pública la vulnerabilidad, la comunidad analizó su impacto práctico. No todas las instalaciones de Alpine se vieron afectadas; el riesgo dependía de la configuración específica.
Los contenedores ligeros destinados únicamente a microservicios no suelen exponer puertos SSH, lo que anula el vector de ataque. Los servidores con la autenticación por contraseña desactivada (PasswordAuthentication no) también resultaban inmunes. Asimismo, las distribuciones que utilizan autenticación PAM delegan la validación a módulos independientes, evitando esta comparación directa.
El verdadero riesgo residía en las plantillas preparadas para la nube. Las imágenes oficiales tiny-cloud de Alpine, entre las versiones 3.18.11 y 3.24.3, incluían por defecto un usuario inicial llamado alpine. En /etc/shadow, el campo de contraseña de este usuario era * y disponía de permisos sudo sin contraseña.
En una máquina recién desplegada, esta cuenta era segura: al no haber otros usuarios con hash y salt, OpenSSH no podía ejecutar el cálculo simulado. Esto llevó a muchos administradores a creer erróneamente que la plantilla básica era invulnerable.
El riesgo detonaba en cuanto el administrador daba de alta el primer usuario convencional. En el momento en que se registraba una cuenta de servicio con contraseña en shadow, la cuenta inactiva alpine se convertía en una puerta trasera de escalada de privilegios remota. Un atacante podía autenticarse mediante una contraseña de 257 bytes y tomar el control total como root.
Reiniciar el servicio es obligatorio tras actualizar los paquetes
No se asignó un identificador CVE exclusivo al momento de la publicación. El investigador Özgün Kültekin descubrió la anomalía, y los equipos de OpenSSH y Alpine coordinaron rápidamente el parche. La solución quedó documentada en las notas de lanzamiento de OpenSSH 10.6p2 y se integró en las ramas de Alpine desde la 3.16 hasta la 3.24 y edge.
Los sistemas afectados deben actualizar sus repositorios de paquetes de inmediato. Al ejecutar apk upgrade -U -a, se reemplaza OpenSSH por la versión corregida. El nuevo código filtra con rigurosidad las respuestas devueltas por la biblioteca base, impidiendo cualquier ambigüedad de símbolos.
Figura: Notas de versión de OpenSSH 10.6p2 con los detalles de corrección para contraseñas extralargas y salts simulados. Fuente: openssh.com.
Es fundamental subrayar que sustituir los binarios en disco no suprime el riesgo en tiempo de ejecución. El servicio sshd previo permanece en memoria ejecutando el código vulnerable. Una vez finalizada la actualización, los administradores deben ejecutar rc-service sshd restart para que la corrección surta efecto.
En entornos de producción donde no sea viable reiniciar el servicio de inmediato, se puede aplicar una mitigación de emergencia deshabilitando la autenticación por contraseña. Basta con añadir PasswordAuthentication no en /etc/ssh/sshd_config.d/00-no-passwords.conf, recargar el servicio y verificar con sshd -T. Durante la revisión de registros, si se observan accesos exitosos en /var/log/messages para cuentas sin contraseña previa, es muy probable que el sistema haya sido vulnerado.
Las brechas de seguridad del software surgen con frecuencia en los límites entre subsistemas. Aunque cada componente cumpla individualmente las mejores prácticas de defensa, una discrepancia sutil en el significado de un símbolo de interfaz puede desmoronar una arquitectura blindada. Mantener la semántica unívoca y estricta en las interfaces sigue siendo un mandato de ingeniería más esencial que acumular capas defensivas.
Enlaces de referencia:
- Aviso de seguridad de Alpine Linux
- Notas de versión de OpenSSH 10.6p2
- Discusión técnica en la comunidad de Lobsters
