OpenSSH lançou a versão portátil 10.6p2 em 5 de novembro de 2026 como atualização emergencial para contornar uma falha de autenticação que afeta sistemas baseados em musl libc, especialmente o Alpine Linux.
O que aconteceu
A vulnerabilidade permite que um atacante autenticado remotamente forneça qualquer senha entre 257 e 1.024 bytes para contas cujo campo de senha em /etc/shadow seja exatamente ‘*’. A condição exige PasswordAuthentication habilitado, acesso à porta SSH e a existência de pelo menos uma conta com hash $5$ ou $6$ no sistema.
Condições técnicas
O problema surge da interação entre o tratamento de senhas curtas em sshd (introduzido após CVE-2016-6210) e o comportamento da função crypt() do musl quando recebe senhas longas em hashes SHA-256 ou SHA-512. Nessas circunstâncias, crypt() retorna o caractere ‘*’ em vez de falhar, fazendo com que o campo ‘*’ do alvo seja considerado correspondente.
Este bypass específico do musl é diferente da regressão crítica do OpenSSH analisada anteriormente no Brainwork, que envolvia uma condição de corrida no tratamento de sinais. A distinção evita aplicar versões afetadas e mitigações de um caso ao outro.
Sistemas que utilizam glibc, PAM habilitado (UsePAM yes) ou que não possuem hashes $5$/$6$ não são afetados. Contas bloqueadas com ‘!’ no shadow também permanecem protegidas.
Sistemas impactados
A Alpine Linux confirmou que todos os branches suportados (3.16 a edge) com o pacote openssh-server padrão (compilado sem PAM) estão expostos. Imagens cloud/tiny-cloud que incluem o usuário ‘alpine’ com doas sem senha e qualquer hash $6$ no sistema tornam-se especialmente críticas.
Outras distribuições musl que executam OpenSSH sem PAM, como certas instalações do OpenWrt, também podem ser afetadas.
Correção e mitigação
A versão 10.6p2 do OpenSSH adiciona uma verificação que recusa correspondência quando o campo de senha armazenado possui menos de quatro caracteres. A Alpine disponibilizou pacotes corrigidos para todos os branches e recomenda executar apk upgrade seguido de reinício do serviço sshd.
Como mitigação imediata, a Alpine sugere desabilitar PasswordAuthentication via sshd_config e validar a configuração com sshd -t antes de reiniciar o daemon.
Recomendações
Administradores de ambientes Alpine devem aplicar a atualização o mais rápido possível e revisar logs de /var/log/messages em busca de aceitações de senha inesperadas em contas que deveriam utilizar apenas chaves. Caso não seja possível descartar acesso indevido, o sistema deve ser tratado como comprometido.
About the Author
