{"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\/pt\/blog\/news\/sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","title":{"rendered":"SSHole \u2014 uma vulnerabilidade que permite a conex\u00e3o via SSH sem senha em sistemas com Musl","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Os desenvolvedores do OpenSSH publicaram uma atualiza\u00e7\u00e3o de emerg\u00eancia OpenSSH 10.6p2, que adiciona prote\u00e7\u00e3o contra uma vulnerabilidade cr\u00edtica (CVE n\u00e3o designado), nomeada «SSHole», que permite contornar a autentica\u00e7\u00e3o. Em sistemas com a biblioteca Musl, a vulnerabilidade permite conectar-se a um usu\u00e1rio sem senha, inserindo qualquer senha que contenha mais de 256 caracteres. O problema afeta distribui\u00e7\u00f5es Linux que utilizam a biblioteca padr\u00e3o musl, mas que n\u00e3o utilizam PAM (M\u00f3dulos de Autentica\u00e7\u00e3o Pluggable), como OpenWRT, Alpine, Buildroot e Yocto. O risco \u00e9 especialmente alto, pois muitas vezes o acesso por senha \u00e9 bloqueado para o usu\u00e1rio root, permitindo que qualquer um se conecte remotamente com privil\u00e9gios de administrador.<\/p>\n
O erro que causa a vulnerabilidade n\u00e3o est\u00e1 no c\u00f3digo do OpenSSH, mas \u00e9 explorado atrav\u00e9s do sshd. Devido \u00e0 gravidade do problema, foi proposta uma alternativa para bloquear a vulnerabilidade na vers\u00e3o OpenSSH 10.6p2. Os propriet\u00e1rios de sistemas afetados s\u00e3o aconselhados a n\u00e3o esperar por atualiza\u00e7\u00f5es e a desativar imediatamente a autentica\u00e7\u00e3o por senha atrav\u00e9s do par\u00e2metro «PasswordAuthentication no» em \/etc\/ssh\/sshd_config ou a desativar completamente o SSH. <\/p>\n
O problema n\u00e3o se manifesta em sistemas diferentes do Linux e em ambientes Linux baseados em glibc, bem como em sistemas que usam PAM para autentica\u00e7\u00e3o por senha. A corre\u00e7\u00e3o j\u00e1 est\u00e1 dispon\u00edvel no Alpine e no OpenWRT.<\/p>\n
A vulnerabilidade est\u00e1 relacionada \u00e0 intera\u00e7\u00e3o inadequada entre o OpenSSH e a fun\u00e7\u00e3o crypt() da musl. Para proteger contra a determina\u00e7\u00e3o da exist\u00eancia de usu\u00e1rios por meio da an\u00e1lise das diferen\u00e7as nos tempos de processamento das solicita\u00e7\u00f5es, desde 2016 o OpenSSH utiliza um procedimento padr\u00e3o de verifica\u00e7\u00e3o de senha ao checar contas sem senha: chama a fun\u00e7\u00e3o «crypt(senha fornecida, sal)» com o sal de outro usu\u00e1rio que possui um hash de senha v\u00e1lido e, em seguida, compara o hash retornado pela fun\u00e7\u00e3o crypt com o valor do campo que cont\u00e9m o hash da senha.<\/p>\n
No entanto, na musl, a fun\u00e7\u00e3o crypt() para hashes SHA-512 retorna o caractere «*» se o comprimento da senha fornecida exceder 256 bytes (limita\u00e7\u00e3o introduzida em 2012 para proteger contra ataques DoS, j\u00e1 que a transmiss\u00e3o de grandes valores imp\u00f5e grande carga na CPU). O mesmo caractere \u00e9 usado no campo com o hash da senha em «\/etc\/shadow» para indicar contas para as quais a autentica\u00e7\u00e3o por senha est\u00e1 bloqueada. <\/p>\n
Como resultado, um atacante que conseguir se conectar a um servidor SSH pode acessar qualquer conta que tenha o s\u00edmbolo '*' no campo de senha do '\/etc\/shadow', transmitindo uma string com comprimento de 257 a 1024 bytes. O problema abrange v\u00e1rias imagens Docker existentes, constru\u00eddas com Alpine Linux, bem como as imagens padr\u00e3o Alpine para sistemas de nuvem AWS e Azure, nas quais o usu\u00e1rio root possui um sinal '*' em vez de um hash de senha. <\/p>\n
Notavelmente, inicialmente nas imagens oficiais do Docker que utilizam Alpine, desde 2015, uma senha vazia para o root era configurada, e ap\u00f3s a descoberta desse fato, um sinal '!' foi inserido em vez do hash de senha. No entanto, sua presen\u00e7a bloqueava o acesso por chaves SSH, ent\u00e3o, a partir de 2022, o s\u00edmbolo para bloquear o login por senha foi substitu\u00eddo por '*'. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"