{"id":184154,"date":"2026-11-05T23:41:11","date_gmt":"2026-11-05T21:41:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/sshole-uyazvimost-pozvolyayushhaya-podklyuchitsya-po-ssh-bez-parolya-v-sistemah-s-musl"},"modified":"2026-11-05T23:41:15","modified_gmt":"2026-11-05T21:41:15","slug":"sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","title":{"rendered":"SSHole \u2014 una vulnerabilidad que permite conectarse por SSH sin contrase\u00f1a en sistemas con Musl","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Los desarrolladores de OpenSSH han publicado una actualizaci\u00f3n urgente OpenSSH 10.6p2, que agrega protecci\u00f3n contra una vulnerabilidad cr\u00edtica (CVE no asignado), apodada 'SSHole', que permite eludir la autenticaci\u00f3n. En sistemas con la biblioteca Musl, la vulnerabilidad permite conectarse a un usuario que no tiene contrase\u00f1a ingresando cualquier contrase\u00f1a que contenga m\u00e1s de 256 caracteres. El problema afecta a distribuciones de Linux que utilizan la biblioteca est\u00e1ndar musl, pero no utilizan PAM (M\u00f3dulos de Autenticaci\u00f3n Pluggable), como OpenWRT, Alpine, Buildroot y Yocto. Lo m\u00e1s preocupante es que el acceso por contrase\u00f1a a menudo est\u00e1 bloqueado para el usuario root, lo que permite que cualquier persona se conecte de forma remota con derechos de administrador.<\/p>\n
El error que lleva a la vulnerabilidad no est\u00e1 en el c\u00f3digo de OpenSSH, sino que se explota a trav\u00e9s de sshd. Dada la seriedad del problema, en la versi\u00f3n OpenSSH 10.6p2 se ha propuesto una soluci\u00f3n alternativa para bloquear la vulnerabilidad. Se recomienda a los propietarios de sistemas afectados que no esperen a que aparezcan actualizaciones, sino que desactiven inmediatamente la autenticaci\u00f3n por contrase\u00f1a a trav\u00e9s del par\u00e1metro 'PasswordAuthentication no' en \/etc\/ssh\/sshd_config o que desactiven completamente SSH. <\/p>\n
El problema no se presenta en sistemas distintos de Linux, ni en entornos de Linux basados en glibc, as\u00ed como en sistemas que utilizan PAM para la autenticaci\u00f3n por contrase\u00f1a. La soluci\u00f3n ya est\u00e1 disponible en Alpine y OpenWRT.<\/p>\n
La vulnerabilidad est\u00e1 relacionada con la interacci\u00f3n incorrecta entre OpenSSH y la funci\u00f3n crypt() de musl. Para protegerse contra la detecci\u00f3n de la existencia de usuarios mediante el an\u00e1lisis de las diferencias en el tiempo de procesamiento de solicitudes, desde 2016 OpenSSH utiliza un procedimiento de verificaci\u00f3n de contrase\u00f1a est\u00e1ndar al verificar cuentas sin contrase\u00f1a: llama a la funci\u00f3n 'crypt(contrase\u00f1a proporcionada, sal)' con la sal de otro usuario que tiene un hash de contrase\u00f1a v\u00e1lido, y luego compara el hash devuelto por la funci\u00f3n crypt con el valor del campo que contiene el hash de contrase\u00f1a.<\/p>\n
Sin embargo, en musl, la funci\u00f3n crypt() para hashes SHA-512 devuelve el car\u00e1cter '*' si la longitud de la contrase\u00f1a proporcionada excede los 256 bytes (l\u00edmite impuesto en 2012 para proteger contra ataques DoS, ya que la transmisi\u00f3n de valores grandes genera una gran carga en la CPU). El mismo car\u00e1cter se utiliza en el campo del hash de contrase\u00f1a en '\/etc\/shadow' para indicar cuentas para las cuales la autenticaci\u00f3n por contrase\u00f1a est\u00e1 bloqueada. <\/p>\n
Como resultado, un atacante con acceso al servidor SSH puede conectarse a cualquier cuenta que tenga el s\u00edmbolo '*' en el campo de contrase\u00f1a en \u00ab\/etc\/shadow\u00bb, enviando una cadena de entre 257 y 1024 bytes. El problema afecta a muchas im\u00e1genes de Docker existentes construidas utilizando Alpine Linux, as\u00ed como a las im\u00e1genes est\u00e1ndar de Alpine para los sistemas en la nube AWS y Azure, donde el usuario root tiene un s\u00edmbolo '*' en lugar de un hash de contrase\u00f1a. <\/p>\n
Es notable que en los Docker oficiales que utilizan Alpine, desde 2015 se configuraba una contrase\u00f1a vac\u00eda para root, y tras descubrirse este hecho, se reemplaz\u00f3 el hash de contrase\u00f1a con un s\u00edmbolo '!'. Sin embargo, su presencia bloqueaba el acceso con claves SSH, por lo que desde 2022 el s\u00edmbolo para bloquear el acceso por contrase\u00f1a se cambi\u00f3 a '*'. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"