Una brecha de seguridad que permita acceso sin contraseña en sistemas Linux

Una vulnerabilidad crítica descubierta recientemente revela cómo determinadas configuraciones de sistemas Linux permiten obtener acceso remoto sin conocer la contraseña del usuario. Esta vulnerabilidad en Linux, catalogada como CVE-2026-123158 y bautizada como *sshole, representa un riesgo importante para administradores de servidores que utilicen distribuciones vulnerables. El fallo fue identificado por el investigador Özgün Kültekin y afecta principalmente a Alpine Linux cuando se utiliza conjuntamente con OpenSSH y la biblioteca musl, sin contar con el mecanismo PAM de autenticación.

El descubrimiento de esta vulnerabilidad en Linux pone de manifiesto cómo medidas de seguridad diseñadas con buenas intenciones pueden generar paradojas inesperadas. Cuando las distribuciones establecen restricciones para que ciertos usuarios no puedan acceder mediante contraseña tradicional, buscan limitar los vectores de ataque. Sin embargo, en este caso particular, esa protección termina permitiendo exactamente lo que debería impedir: un acceso no autorizado al sistema.

¿Cómo funciona la vulnerabilidad en Linux?

Para comprender esta brecha de seguridad, es fundamental entender el rol de SSH, el protocolo que permite conexiones seguras a servidores remotos. OpenSSH es la implementación más utilizada y típicamente soporta dos métodos de autenticación: contraseñas y claves criptográficas. En sistemas Linux, el archivo /etc/shadow almacena los datos necesarios para verificar las contraseñas de las cuentas de usuario.

El mecanismo de protección en cuestión utiliza un asterisco (*) en el campo de contraseña del archivo /etc/shadow para indicar que la autenticación mediante contraseña debe bloquearse en esa cuenta. Teóricamente, esto debería impedir cualquier acceso usando contraseña tradicional, permitiendo solo otros métodos como claves SSH. Sin embargo, el fallo en esta vulnerabilidad en Linux surge de una interacción inesperada entre varios componentes del sistema.

La cadena de eventos que origina el problema

Cuando OpenSSH verifica una contraseña para una cuenta que no debería aceptarlas, recurre a información de otra cuenta para realizar la verificación. Aquí es donde interviene musl, la biblioteca utilizada por Alpine Linux. Cuando una contraseña tiene entre 257 y 1.024 bytes de longitud, la función de procesamiento en musl devuelve un asterisco para señalar un error en el procesamiento. El problema crítico ocurre porque ese mismo símbolo existe en la cuenta protegida: el servidor interpreta ambos valores como coincidentes y concede acceso al usuario.

Esta secuencia de eventos es tan específica y particular que requiere múltiples condiciones simultáneamente para manifestarse. Primero, OpenSSH debe estar funcionando sin PAM. Segundo, debe tener habilitada la autenticación por contraseña. Tercero, debe haber una cuenta local con el campo de contraseña en asterisco. Finalmente, debe existir otra cuenta con un hash generado mediante SHA-256 o SHA-512. Cuando todas estas condiciones convergen, la vulnerabilidad en Linux se activa.

Una década de historia técnica tras el fallo

La génesis de esta vulnerabilidad en Linux se remonta a años atrás, con una serie de cambios aparentemente independientes que terminaron interactuando de forma imprevista. En 2012, musl implementó modificaciones en cómo comunica ciertos errores y estableció límites en la longitud de contraseñas procesadas para prevenir ataques de denegación de servicio. Cuatro años más tarde, en 2016, OpenSSH introdujo cambios para impedir que posibles atacantes pudieran enumerar usuarios existentes midiendo los tiempos de respuesta del servidor.

Posteriormente, en 2022, Alpine Linux ajustó la configuración de su cuenta administrativa para permitir acceso mediante claves SSH. Cada una de estas modificaciones respondía a legítimos problemas de seguridad, pero al combinarse generaron una situación imprevista que ninguno de los desarrolladores anticipó. Este es un ejemplo clásico de cómo en seguridad informática las interacciones entre capas diferentes del software pueden crear vulnerabilidades emergentes.

¿Qué sistemas están realmente en riesgo?

Aunque Alpine Linux es el principal afectado, la vulnerabilidad en Linux no afecta automáticamente a todos los sistemas que usen esta distribución. Según análisis de firmas de ciberseguridad como Check Point, se requieren varias condiciones simultáneamente para que el fallo sea explotable. Los sistemas que desactivan completamente la autenticación por contraseña no corren riesgo. Del mismo modo, aquellos que utilizan PAM para gestionar la autenticación quedan fuera del escenario de vulnerabilidad.

El riesgo es particularmente grave en determinadas imágenes oficiales de Alpine utilizadas en entornos en la nube. Algunas de estas imágenes permiten al usuario alpine ejecutar comandos de administrador mediante doas sin requerir contraseña. Aunque estas imágenes son seguras en su arranque inicial, pueden volverse vulnerables si posteriormente se configura una cuenta con un hash de contraseña compatible. En ese caso, un atacante podría potencialmente alcanzar control total del sistema con privilegios de administrador.

Evidencia de explotación activa

Ya existen indicios de que esta vulnerabilidad en Linux está siendo explotada en la práctica. La firma Previdian reportó haber detectado ocho intentos de ataque desde una misma dirección IP, confirmando un acceso exitoso con privilegios de administrador en uno de sus servidores señuelo diseñados para monitorear intentos de ataque. Esto indica que actores maliciosos ya conocen y utilizan esta brecha de seguridad.

Medidas de mitigación y parches disponibles

La respuesta a este descubrimiento fue rápida. El 5 de noviembre, OpenSSH lanzó la versión 10.6p2 que corrige específicamente este fallo. Simultáneamente, Alpine distribuyó actualizaciones de seguridad para diversas ramas de su sistema operativo, incluyendo versiones antiguas de soporte extendido. Sin embargo, simplemente instalar los parches no es suficiente: es imperativo reiniciar el servicio SSH para que utilice el código corregido.

Para aquellos usuarios que no pueden actualizar inmediatamente, la recomendación oficial es desactivar la autenticación mediante contraseña en OpenSSH. Este cambio también requiere reiniciar el servicio SSH para entrar en vigor. Antes de aplicar esta medida, es crítico verificar que el acceso mediante claves SSH funciona correctamente, evitando quedarse bloqueado fuera del sistema.

Conclusiones sobre esta vulnerabilidad en Linux

La vulnerabilidad en Linux catalogada como CVE-2026-123158 ilustra un principio fundamental en seguridad informática: la complejidad puede generar riesgos inesperados. Aunque cada modificación individual respondía a problemas de seguridad legítimos, su combinación creó una brecha que permaneció oculta durante años. Los administradores de sistemas que utilicen Alpine Linux con OpenSSH deben aplicar los parches de seguridad cuanto antes y verificar que sus configuraciones no reúnen las condiciones específicas que hacen el sistema vulnerable a esta amenaza.