El fallo de OpenSSH en Alpine ya tiene parche

Seguimiento de Un fallo crítico de OpenSSH pone en riesgo Alpine, publicada el 5 de noviembre.

Como contamos ayer, OpenSSH preparaba una mitigación urgente para un fallo grave en sistemas Linux con musl y sin PAM, como Alpine. Ya hay parche y se conocen los detalles. El fallo se llama SSHole, está registrado como CVE-2026-123158 con una puntuación CVSS de 8,1 (severidad alta) y, según SecurityWeek, la corrección llega con OpenSSH 10.6p2.

Cualquier contraseña larga vale

El problema es una «mala interpretación de si una cadena debe tratarse como un hash de contraseña». En la práctica, un atacante puede entrar en ciertas cuentas con cualquier contraseña de entre 257 y 1.024 caracteres. Damien Miller, desarrollador de OpenSSH, insiste en que el error no está en sshd, aunque se puede explotar a través de él.

Alpine Linux concreta las condiciones. El ataque funciona si OpenSSH corre sin PAM, con la autenticación por contraseña activada, y si hay:

• Una cuenta con el campo de contraseña en «*», lo normal en cuentas que solo usan clave. Por ejemplo, root (Alpine lo protege así desde la 3.16), un usuario creado con adduser sin contraseña, el usuario alpine de las imágenes oficiales tiny-cloud o usuarios que llegan de un directorio mediante musl-nscd.
• Al menos otra cuenta local con un hash $5$ o $6$ (SHA-256 o SHA-512).

Alpine reconoce que todas las versiones que ha comprobado están afectadas: de la 3.21 a la 3.24, edge y las antiguas de la 3.16 a la 3.20, que ya no reciben actualizaciones regulares. Su resumen no deja lugar a dudas: quien llegue al puerto SSH puede entrar sin saber ninguna contraseña, «con una sola conexión, funciona siempre y no necesita reintentos». El investigador Özgün Kültekin, de Wakefield, cita además OpenWrt, Buildroot y Yocto entre las distribuciones donde cuentas como root, que nunca deberían aceptar contraseña, acaban aceptándola.

Sin embargo largo, por culpa de la IA

Miller explica que supieron del problema la víspera del parche y que lo publicaron lo antes posible porque han visto «varios casos de redescubrimiento rápido de fallos por agentes de IA, a veces en cuestión de horas». Por eso ahora consideran los embargos largos «una práctica peligrosa que beneficia sobre todo a los atacantes».

Por ahora no constan ataques, pero nadie espera que dure. Fredrik Almroth, de Detectify, calcula que los escaneos empezarán en horas: Shodan cuenta unos 22 millones de sistemas con SSH abierto en el puerto 22 y cada intento cuesta una sola conexión. Jake Knott, de WatchTowr, se sorprendería mucho si los atacantes que prueban contraseñas por fuerza bruta no lo intentaran antes del fin de semana.

Qué hacer

Alpine pide aplicar ya los parches de OpenSSH y reiniciar sshd para que deje de correr el proceso vulnerable. Si no se puede actualizar, hay que desactivar el acceso por contraseña (PasswordAuthentication no) y reiniciar igualmente. Conviene revisar también contenedores e imágenes basadas en Alpine, no solo los servidores a la vista.

Fuente: SecurityWeek