Osegi
Seguridad·2 min de lectura

sshhole: fallo en OpenSSH sobre Linux musl abre cuentas sin clave

El fallo crítico sshhole afecta a OpenSSH en Linux con musl, como Alpine, desde 2016: las cuentas sin contraseña aceptan cualquier clave de más de 256 caracteres.

A padlock icon over a terminal window showing an SSH login prompt, symbolizing an OpenSSH authentication flaw.
Imagen: Хабр

Se ha revelado una vulnerabilidad crítica llamada sshhole en OpenSSH sobre sistemas Linux que usan la biblioteca C musl. El fallo existe desde 2016 y permite acceder a cuentas que no están protegidas con contraseña. Afecta, entre otros, a Alpine, OpenWrt, Buildroot y Yocto, además de muchas imágenes de Docker.

Cómo funciona el error

Las cuentas que en principio no deberían exigir contraseña, con el carácter * en ese campo, empiezan a aceptar cualquier contraseña de más de 256 caracteres. Entre los ejemplos están root, un usuario de despliegue que solo emplea claves SSH, los usuarios de LDAP y el usuario por defecto de las imágenes de Alpine para AWS y Azure. Según la divulgación, para una cuenta así se acepta cualquier contraseña de entre 257 y 1024 caracteres.

Un sistema solo es vulnerable si se dan varias condiciones a la vez: sshd funciona en un sistema con musl, no se usa PAM, el acceso por contraseña está permitido (opción predeterminada) y existe una cuenta con * como contraseña. Además, debe haber otra cuenta con una contraseña real. En Alpine, el paquete openssh-server viene configurado sin PAM por defecto, y algunos administradores también fijan UsePAM no de forma explícita.

Quién está expuesto

El riesgo es mayor en las imágenes oficiales de Alpine para AWS y Azure. Su usuario por defecto, alpine, tiene esa configuración y puede ejecutar comandos con doas sin contraseña, lo que equivale en la práctica a privilegios de root.

Debian, Ubuntu, Fedora y cualquier otra distribución basada en glibc no están afectadas. Tampoco lo están los sistemas con PAM configurado, ni dropbear ni la implementación de OpenSSH de OpenBSD.

La solución

El problema se corrige en OpenSSH 10.6p2. Los administradores de sistemas con musl, sobre todo de instancias en la nube e imágenes de contenedores basadas en Alpine, deberían revisar su configuración y actualizar. Desactivar el acceso por contraseña cuando no se necesita también cierra esta vía de ataque.

Apps que merecen la pena

SUMO: el puzle de números

Toca las casillas correctas, suma y alcanza el objetivo. Fácil de aprender, difícil de dominar. Gratis, para todas las edades.

Etiquetas:opensshsshholemuslalpine linuxvulnerabilitydocker

Más de este día

Ver todas →

Más en: Seguridad

Ver todas →