Bug de 13 anos no OpenSSH libera root sem senha no Alpine Linux

Uma falha batizada pela comunidade de segurança como *sshole permite autenticar sem senha em contas SSH bloqueadas ou configuradas para login só com chave, em qualquer sistema que rode o OpenSSH sobre a libc musl — caso do Alpine Linux, usado em boa parte das imagens de contêiner. O bug existe desde 2012 e afeta as versões 3.16 a 3.24 e a edge do Alpine. A correção já foi publicada e não exige nenhuma mitigação além da atualização.

Qual é o problema

A causa é a combinação de dois comportamentos da musl. Desde 2012, a função crypt() da musl devolve a string "*" quando falha, em vez de NULL como a maioria das libc faz. Além disso, o crypt() da musl recusa qualquer senha com mais de 256 bytes e também devolve "*" nesse caso — tratando “senha grande” e “erro” do mesmo jeito.

O problema aparece porque contas bloqueadas (passwd -l) ou configuradas para aceitar apenas chave pública gravam exatamente "*" no campo de senha do arquivo etc/shadow. Quando o sshd é compilado sem PAM (o padrão no Alpine) ou roda com UsePAM no, ele mesmo faz a comparação com o crypt() do sistema. Um atacante que envie, via SSH, uma senha com 257 a 1024 bytes de comprimento força o crypt() a retornar "*" — que bate com o "*" gravado na conta travada, e o sshd autentica o acesso.

Quem é afetado

• Alpine Linux — pacote openssh-server nas versões 3.16 até 3.24 e na edge, sempre que PasswordAuthentication estiver habilitado (é o padrão).
• Outros sistemas baseados em musl — OpenWrt, Buildroot, Yocto e qualquer imagem de contêiner que rode sshd sobre musl sem PAM.
• Não afetados — distribuições com glibc (Debian, Ubuntu, RHEL, CentOS, entre outras), sshd compilado com PAM habilitado, o daemon alternativo Dropbear e sistemas que não sejam Linux.

Até a publicação deste texto nenhum CVE havia sido atribuído à falha, e os pesquisadores não relataram exploração confirmada em produção — mas já existe prova de conceito pública reproduzível, o que reduz bastante a margem para esperar.

O que fazer agora

1. Atualize o OpenSSH para a 10.6p2 (versão upstream corrigida). No Alpine, use o gerenciador de pacotes para subir para a versão corrigida do seu branch: edge → 10.6_p2-r0, 3.24 → 10.3_p1-r2, 3.23 → 10.2_p1-r1, 3.22 → 10.0_p1-r11, 3.21 → 9.9_p2-r1, 3.20 → 9.7_p1-r6.
2. Reinicie o serviço sshd depois do upgrade — atualizar o pacote não troca o daemon que já está em execução.
3. Se não puder corrigir agora, defina PasswordAuthentication no no sshd_config como mitigação temporária; isso fecha a rota de ataque mesmo sem o patch.
4. Audite os logs de autenticação em busca de entradas "Accepted password for" associadas a contas sem senha definida. Qualquer host com esse padrão deve ser tratado como potencialmente comprometido.
5. Priorize servidores Alpine expostos à internet com login por senha habilitado — é o cenário de maior risco.

Perguntas frequentes

Minha distribuição Ubuntu, Debian ou RHEL está vulnerável?
Não. A falha depende de um comportamento específico da libc musl; distribuições baseadas em glibc não são afetadas.

Containers Docker baseados em Alpine estão em risco?
Sim, se a imagem expõe o sshd com autenticação por senha sobre musl sem PAM. Imagens Alpine que só usam SSH para build, sem serviço exposto, não são afetadas.

Habilitar autenticação só por chave pública já resolve?
Não sozinho. É justamente o cenário de contas “só com chave” que a falha explora, porque elas também gravam "*" no campo de senha. É necessário atualizar o OpenSSH ou desabilitar PasswordAuthentication.

Já existe CVE registrado para acompanhar o caso?
Até a publicação desta notícia, não. Vale monitorar o changelog de segurança do Alpine e do OpenSSH para a atribuição posterior.

Conclusão

É uma falha antiga, de baixa complexidade para explorar e com correção pronta — a combinação que mais pesa a favor de agir hoje, antes que apareça prova de conceito automatizada em massa. Quem mantém imagens Alpine ou qualquer base musl com sshd exposto deve tratar a atualização como prioridade, não como item de backlog.