*sshole: falha no OpenSSH permite login sem senha em alguns sistemas Alpine Linux

A *sshole nasce da interação entre o OpenSSH e a musl, a alternativa leve à libc usada pelo Alpine Linux. Para a exploração funcionar, o OpenSSH precisa estar compilado com musl e sem PAM. Além disso, o sistema precisa ter ao menos uma conta cujo hash use SHA256 ou SHA512, e a conta alvo deve estar ativa e sem senha, com "*" no campo de senha do /etc/shadow. Esse padrão é comum em contas que usam autenticação por certificado.

Com tudo isso presente, o invasor envia mais de 256 caracteres no campo de senha e entra em uma única conexão, sem retentativas. A Checkpoint afirma que o sshd empresta o salt dessa conta, e sem ele o ataque falha. Contas root ficam protegidas pela configuração padrão PermitRootLogin prohibit password, mas contas alcançáveis com direitos de doas ou sudo ainda podem virar root. A origem do bug é disputada: o OpenSSH diz que a causa raiz está fora do sshd, mas que dá para evitá-la nele, e o desenvolvedor da musl, Rich Felker, afirma que se trata de uso errado pelo chamador, embora a musl planeje mudar o mecanismo em versão futura. Alpine e OpenSSH já publicaram atualizações. Não há CVE conhecido. OpenWRT, buildroot e yocto foram citados como possivelmente afetados, mas só o OpenWRT foi apontado pelo descobridor com mais clareza, e usa Dropbear por padrão.

Em 6 de novembro de 2026, o CEVIU noticiou "Alpine Linux alerta para falha no openssh-server que permite burlar a autenticação por senha", com o aviso do Alpine para as versões de 3.16 a 3.24. No mesmo dia, saiu "Falha no OpenSSH permite bypass de autenticação por senha em sistemas com musl sem PAM", que apontava a causa no marcador de falha da função crypt() da musl. Agora o quadro está mais completo: o nome *sshole, a exigência de hash SHA256 ou SHA512, a conta ativa, a escala potencial (Docker Hub, embarcados) e a discussão sobre de quem é a responsabilidade pelo bug.

Para quem opera containers e dispositivos embarcados baseados em Alpine, a leitura é prática: inventarie imagens com musl e OpenSSH sem PAM e procure contas com "*" em /etc/shadow. Em embarcados que quase não recebem atualização, o risco tende a durar mais. Como a exploração é rápida de testar, vale tratar o patch como prioridade, sem alarmismo, já que os pré-requisitos reduzem a superfície.