Grave fallo en OpenSSH para Alpine Linux permite iniciar sesión con contraseñas largas

Una vulnerabilidad crítica en OpenSSH permite a los atacantes eludir la autenticación en configuraciones específicas de Alpine Linux mediante el envío de contraseñas excesivamente largas. El proyecto OpenSSH lanzó la versión 10.6p2 el 5 de noviembre de 2026 para abordar este problema, mientras que Alpine Linux ha portado las correcciones a todas sus versiones compatibles.

Qué ocurrió

Los atacantes con acceso a la red pueden iniciar sesión en cuentas de usuario que no tienen contraseña establecida, como usuarios que solo usan claves SSH o el usuario predeterminado alpine en imágenes cloud. Para tener éxito, el atacante necesita conocer el nombre de la cuenta y debe proporcionar una contraseña de entre 257 y 1.024 bytes de longitud. Este fallo afecta específicamente a los sistemas que ejecutan el paquete estándar openssh-server en Alpine Linux, el cual se compila sin la interfaz del Módulo de Autenticación Pluggable (PAM).

La vulnerabilidad surge de una interacción entre la lógica de verificación de contraseñas de OpenSSH y musl, la biblioteca C utilizada por Alpine. Cuando la autenticación por contraseña está habilitada y al menos otra cuenta local tiene un hash de contraseña, el servidor acepta incorrectamente la contraseña larga para cualquier cuenta con un campo de contraseña vacío. Aunque no se han reportado exploits activos, el equipo de OpenSSH calificó el fallo como crítico e instó a aplicar mitigaciones inmediatas.

Damien Miller, del proyecto OpenSSH, enfatizó la urgencia, declarando que los administradores deben "establecer PasswordAuthentication=no o deshabilitar SSH para estos sistemas INMEDIATAMENTE". La corrección se liberó rápidamente, y Miller señaló que los embargos prolongados son cada vez más peligrosos, ya que los agentes de IA pueden redescubrir tales errores en cuestión de horas.

Cómo funciona

La causa raíz reside en cómo sshd maneja la verificación de contraseñas cuando no se utiliza PAM. Normalmente, sshd genera el hash de la contraseña proporcionada usando la función crypt() y lo compara con el hash almacenado en /etc/shadow. Las cuentas sin contraseña tienen el carácter * en este campo. Dado que * es demasiado corto para contener una sal, sshd toma prestada la sal de otra cuenta que sí tiene un hash de contraseña.

Cuando un atacante envía una contraseña de más de 256 bytes, la función crypt() de musl se niega a procesarla y devuelve * para indicar un error. Como el campo almacenado para la cuenta objetivo también es *, la comparación tiene éxito y el servidor concede el acceso. Este comportamiento proviene de un cambio realizado en musl en 2012, diseñado para evitar fallos en programas que no verificaban los errores de crypt(), combinado con un cambio en OpenSSH de 2016 destinado a prevenir la enumeración de nombres de usuario.

La nueva versión, 10.6p2, introduce una solución alternativa que rechaza cualquier coincidencia si el campo de contraseña almacenado tiene menos de cuatro caracteres. Si bien esto detiene el ataque, el equipo de OpenSSH señala que el problema subyacente radica en el manejo de entradas largas por parte de la biblioteca C, y no en SSH mismo.

Detalles clave

• Sistemas afectados: Alpine Linux ejecutando openssh-server sin PAM, o openssh-server-pam con UsePAM no.
• Requisitos previos: PasswordAuthentication debe estar en yes, al menos una cuenta debe tener un hash $5$ o $6$, y la cuenta objetivo debe tener * en su campo de contraseña.
• Vector de ataque: Un único intento de conexión con una contraseña de entre 257 y 1.024 bytes tiene éxito siempre.
• Objetivos de alto riesgo: El usuario alpine en imágenes tiny-cloud (versiones 3.18.11 a 3.24.3) es vulnerable una vez que existe cualquier hash de contraseña en el sistema, lo que podría permitir acceso root mediante doas.
• Sistemas no afectados: Distribuciones Linux que usan glibc, sistemas que utilizan PAM para la autenticación y dispositivos OpenWrt que usan Dropbear.
• Disponibilidad de la corrección: OpenSSH 10.6p2 está disponible ahora; Alpine ha actualizado los paquetes para las versiones 3.16 a 3.24.

Por qué importa

Para los ingenieros que construyen infraestructura sobre Alpine Linux, esta vulnerabilidad socava la seguridad de las configuraciones de autenticación basada únicamente en claves. Muchos desarrolladores confían en Alpine por su pequeño tamaño en contenedores e instancias cloud, asumiendo a menudo que deshabilitar los inicios de sesión por contraseña o usar claves SSH ofrece protección suficiente. Sin embargo, dado que PasswordAuthentication está habilitado por defecto en muchas configuraciones, estos sistemas permanecen expuestos hasta que se endurecen explícitamente.

El incidente también destaca la creciente presión sobre los mantenedores de código abierto para publicar parches rápidamente. La decisión de omitir un embargo tradicional refleja un panorama de amenazas cambiante donde las herramientas automatizadas pueden realizar ingeniería inversa de vulnerabilidades con rapidez. Los equipos deben priorizar ahora ciclos de parcheo rápidos y asumir que los detalles técnicos de fallos críticos podrían hacerse públicos casi inmediatamente después de su descubrimiento.

Qué puede hacer

• Actualice sus paquetes de Alpine inmediatamente usando apk upgrade -U -a y reinicie el servicio SSH con rc-service sshd restart.
• Si no puede actualizar de inmediato, deshabilite la autenticación por contraseña estableciendo PasswordAuthentication no en su configuración de SSH.
• Verifique sus cambios de configuración ejecutando sshd -T | grep -i passwordauthentication para asegurarse de que devuelva no.
• Revise /var/log/messages buscando entradas que muestren Accepted password for para usuarios como root o alpine, quienes no deberían tener acceso por contraseña.
• Revise el uso de doas y los usuarios creados recientemente en cualquier máquina potencialmente expuesta, tratándolas como comprometidas si se encuentra actividad sospechosa.
• Audite otros sistemas basados en musl, como Buildroot o Yocto, si ejecutan OpenSSH, aunque OpenWrt suele ser seguro si usa Dropbear.