OpenSSH 10.6p2 cierra fallo crítico de autenticación en Alpine Linux

Introducción

La gestión de credenciales en entornos minimalistas suele esconder riesgos silenciosos que solo se activan bajo condiciones específicas de configuración y librerías base. Un nuevo incidente de seguridad ha expuesto una falla lógica en la validación de contraseñas dentro de OpenSSH cuando este opera sobre sistemas basados en la biblioteca C musl, como Alpine Linux. El problema no reside en algoritmos criptográficos débiles ni en implementaciones rotas del protocolo, sino en cómo el demonio sshd maneja las respuestas de error de la función crypt() al procesar entradas de longitud excesiva.

Para los equipos de infraestructura que dependen de imágenes ligeras para contenedores o instancias cloud efímeras, este hallazgo obliga a revisar supuestos básicos sobre la seguridad de cuentas con autenticación exclusiva por clave pública. Aunque el vector de ataque requiere condiciones precisas —como tener otras cuentas con hash de contraseña activo—, la consecuencia es un bypass total de autenticación que permite iniciar sesión como usuario sin credenciales válidas configuradas. OpenSSH ha liberado la versión 10.6p2 para mitigar este comportamiento, mientras Alpine distribuye parches para todas sus ramas activas y mantenidas.

Qué ocurrió

Investigadores de seguridad reportaron un mecanismo por el cual un atacante puede autenticarse con éxito en cuentas que no poseen contraseña asignada (representadas internamente por * en /etc/shadow). El ataque funciona enviando una cadena de texto de entre 257 y 1.024 bytes como password. En sistemas estándar basados en glibc, esta entrada simplemente falla la comparación hash. Sin embargo, en entornos Alpine que no utilizan PAM (Pluggable Authentication Modules), el flujo lógico cambia drásticamente.

La causa raíz combina dos factores históricos: un cambio en musl de 2012 que hace que crypt() devuelva un string * en lugar de NULL ante errores o límites de longitud, y una modificación en OpenSSH de 2016 (relacionada con CVE-2016-6210) que introdujo la lógica de «préstamo» de salt cuando el campo almacenado es demasiado corto. Cuando sshd intenta validar un password largo contra una cuenta vacía, musl rechaza la entrada por exceder los 256 bytes permitidos para ciertos hashes y devuelve *. Dado que el hash almacenado en la cuenta objetivo también es *, la comparación lógica evalúa como verdadero, aceptando la sesión.

Este comportamiento afecta exclusivamente a configuraciones donde PasswordAuthentication está habilitado (por defecto en Alpine) y PAM no interviene en la validación local de sshd. Si el sistema usa PAM para delegar la autenticación, la capa adicional intercepta el error antes de que ocurra la comparación directa. Damien Miller, líder del proyecto OpenSSH, clasificó esto como crítico debido a la facilidad de explotación y la ausencia de requisitos complejos, más allá de conocer un nombre de usuario existente y tener acceso de red al puerto 22.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

El impacto principal recae en servidores Alpine Linux que usan el paquete estándar openssh-server sin configuraciones personalizadas restrictivas. Las imágenes «tiny-cloud» de Alpine (versiones 3.18.11 a 3.24.3) son particularmente vulnerables si un administrador habilita el acceso root directo o configura usuarios con permisos elevados mediante doas. Por defecto, estas imágenes otorgan al usuario alpine capacidad de ejecutar comandos como root sin contraseña (doas). Si la vulnerabilidad permite iniciar sesión como alpine, el atacante obtiene inmediatamente privilegios de administrador mediante ese mismo comando.

Es crucial distinguir entre entornos afectados y no afectados. Los sistemas basados en glibc (Ubuntu, Debian, CentOS/RHEL) no sufren este problema específico debido a diferencias en la implementación de crypt() y el manejo de errores. Del mismo modo, los contenedores que no ejecutan un demonio SSH activo están fuera de riesgo directo. Sin embargo, cualquier instancia cloud provisionada con Alpine donde se haya establecido al menos una contraseña real para otro usuario (por ejemplo, configurando la consola o creando un admin humano) expone a todos los usuarios «sin contraseña» al vector de ataque.

La ausencia de logs claros puede complicar la detección forense. El sistema registra el acceso como exitoso («Accepted password») aunque no hubo verificación criptográfica real válida. Esto significa que en auditorías de seguridad, una entrada legítima podría verse idéntica a un exploit exitoso si no se correlaciona con la longitud del payload o las horas pico de acceso anómalo. La rápida propagación de este bug en ecosistemas musl (OpenWrt y Buildroot también son candidatos si usan OpenSSH) exige una revisión transversal de la flota de servidores ligeros.

Detalles técnicos

La vulnerabilidad se dispara bajo cuatro condiciones simultáneas: el sistema usa musl como libc, sshd no delega en PAM, PasswordAuthentication es yes, y existe al menos una cuenta con un hash válido ($5$ o $6$). El código vulnerable proviene de la lógica introducida para mitigar CVE-2016-6210. Originalmente, si el campo de contraseña era vacío (*), OpenSSH tomaba prestado el «salt» de una cuenta vecina con hash válido para evitar timing attacks que revelaran la existencia de usuarios.

Sin embargo, musl impone un límite duro de 256 bytes para las funciones crypt() de SHA-256 y SHA-512 por razones históricas de prevención de DoS. Si se pasa una cadena mayor, no retorna NULL (que sshd trataría como error explícito), sino que devuelve un string * genérico. La lógica de comparación en sshd ve:

1. Input largo > 256 bytes -> crypt() devuelve *.
2. Stored hash == *.
3. Comparación == -> True.

El parche en OpenSSH 10.6p2 introduce una verificación adicional: si el campo almacenado es más corto de 4 caracteres, se rechaza la autenticación inmediatamente antes de intentar la comparación de hash, evitando así el falso positivo generado por el retorno de error de musl. No se ha asignado un nuevo CVE a esta variante específica hasta el momento del parche, pero está relacionada intrínsecamente con la familia de fallos de manejo de hashes vacíos.

Qué deberían hacer los administradores y equipos técnicos

La acción inmediata es actualizar el paquete openssh-server en todos los hosts Alpine Linux. Las versiones corregidas ya están disponibles para las ramas 3.16 a 3.24, incluyendo point releases específicos como 3.18.11, 3.21.10, 3.22.8, 3.23.8 y 3.24.4.

Para aplicar el cambio en un sistema Alpine existente:

apk update
apk upgrade openssh-server
rc-service sshd restart

Note que actualizar el paquete no reinicia automáticamente el servicio activo; el paso de restart es obligatorio para cargar la nueva lógica binaria o los parches aplicados a la configuración. Si no es posible reiniciar inmediatamente, aplicar una mitigación de configuración es vital. Deshabilitar la autenticación por contraseña fuerza al sistema a usar solo claves públicas, evitando el código vulnerable de crypt().

Antes de hacer cambios, asegúrese de tener una sesión SSH abierta con acceso garantizado para no bloquearse fuera del servidor. Puede aplicar la mitigación creando un archivo drop-in:

echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/99-security.conf
sshd -t && rc-service sshd reload

Verifique que la configuración efectiva haya cambiado correctamente:

sshd -T | grep -i passwordauthentication
# Salida esperada: passwordauthentication no

Finalmente, audite los logs en /var/log/messages buscando entradas Accepted password for alpine o usuarios similares sin contraseña asignada durante el periodo de vulnerabilidad. Si se encuentran accesos sospechosos que no coinciden con sus procedimientos operativos estándar, trate la máquina como comprometida y realice una revisión forense completa.

Conclusión

Este incidente subraya la fragilidad inherente a las dependencias de bajo nivel en distribuciones minimalistas. La combinación de musl y OpenSSH sin PAM crea un nicho donde los supuestos estándar de manejo de errores criptográficos no se sostienen. Para los equipos DevOps, la lección técnica es clara: la seguridad por defecto en Alpine Linux requiere una configuración explícita (PasswordAuthentication no) para cerrar vectores que en otras distros son mitigados por capas adicionales como PAM o glibc.

La respuesta rápida de OpenSSH y Alpine, liberando parches en horas/días, demuestra la madurez del ecosistema, pero también la necesidad de monitoreo activo en imágenes cloud efímeras. Los administradores deben priorizar la actualización inmediata y verificar que sus pipelines de aprovisionamiento no estén desplegando versiones obsoletas de openssh-server en entornos sensibles expuestos a internet.

Fuentes

https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html

https://www.infosecurity-magazine.com/