Alpine Linux corrige falha no openssh-server que permitia login sem senha

O que foi descoberto

A equipe do Alpine Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → publicou em 5 de novembro de 2026 um advisory de segurança descrevendo um bypass na autenticação por senha do openssh-server. Um atacante que alcance a porta SSH consegue logar sem saber nenhuma senha. Uma única conexão basta: não é preciso repetir tentativas nem forçar nada.

O bug foi corrigido no OpenSSH 10.6p2, mas até a publicação do advisory nenhum identificador CVE havia sido atribuído. O relato é de Özgün Kültekin, da Wakefield, com análise de Timo Teräs e correção de Damien Miller e Darren Tucker, do projeto OpenSSH. Natanael Copa empacotou e publicou as versões corrigidas para o Alpine.

Como o ataque funciona

O problema mora em como o sshd sem PAM valida senhas. Ele usa a função crypt() da libc para transformar a tentativa de senha em hash e compara o resultado com o campo armazenado em /etc/shadow. Quando esse campo é curto demais para conter um salt (o prefixo aleatório do hash), o sshd toma emprestado o salt de outra conta do sistema.

A musl, libc usada pelo Alpine, tem um comportamento específico: sua crypt() retorna a string * como indicador de erro quando a senha enviada passa de 256 bytes. Só que * é exatamente o que o campo de senha contém em contas sem senha definida (comuns em usuários só-chave). O atacante manda uma senha de 257 a 1024 bytes, o hash de erro bate com o campo *, e o login é aceito.

Para o ataque funcionar, duas condições precisam coexistir na máquina:

• Existir uma conta cujo campo de senha é * (conta sem senha, normal em usuários configurados só com chave SSH).
• Existir pelo menos uma outra conta com hash de senha $5$ ou $6$ no sistema.

Basta um único usuário com senha cadastrada para tornar toda conta sem senha alcançável por qualquer pessoa que saiba o nome dela.

Quem está exposto

A Alpine confirma o bug em todas as versões suportadas (3.21 a 3.24 e edge) e também nas que já saíram de suporte regular (3.16 a 3.20). Mas nem todo servidor com Alpine está vulnerável: depende de uma combinação específica de configuração.

Contêineres Docker que não rodam sshd dentro do container não são afetados, assim como imagens cloud configuradas via cloud-init, que já escrevem PasswordAuthentication no por padrão.

O caso de root merece atenção à parte: desde cerca da versão 3.16, a imagem base do Alpine já traz root:* por padrão. A proteção padrão do OpenSSH, PermitRootLogin prohibit-password, bloqueia esse vetor específico para root — a não ser que alguém tenha ligado PermitRootLogin yes, ou que outra conta explorável consiga virar root via doas.

Imagens cloud do tiny-cloud também entram na lista

As imagens oficiais tiny-cloud (artefatos qcow2, VHD e AMI) das versões 3.18.11 até 3.24.3 trazem um usuário alpine com campo de senha * e doas sem senha liberado. No primeiro boot elas são seguras, porque ainda não existe nenhum hash $6$ na máquina.

Elas deixam de ser seguras assim que qualquer hash desse tipo aparece, por exemplo quando um administrador define uma senha de console ou quando user-data do cloud-init cria um usuário com hashed_passwd. A partir daí, um atacante ganha shell como alpine e usa doas para virar root.

Imagens geradas a partir das versões 3.21.10, 3.22.8, 3.23.8, 3.24.4 e posteriores já saem com o pacote corrigido. Instâncias já em execução, construídas a partir de versões anteriores, precisam ser atualizadas manualmente ou ter a autenticação por senha desligada.

Como corrigir

A correção recomendada pela Alpine é simples: atualizar o pacote e reiniciar o daemon. Atualizar sozinho não é suficiente, porque o sshd em execução continua rodando o binário antigo até ser reiniciado.

apk upgrade -U -a
rc-service sshd restart

As versões corrigidas por branch são:

Quem não pode atualizar agora tem uma saída imediata: desligar a autenticação por senha. Antes de rodar os comandos, garanta que o login por chave SSH funciona e mantenha a sessão atual aberta até confirmar que o novo acesso está liberado.

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

O último comando precisa imprimir passwordauthentication no. Para desfazer, apague o arquivo /etc/ssh/sshd_config.d/00-no-passwords.conf e restaure /etc/ssh/sshd_config.bak sobre /etc/ssh/sshd_config.

Como saber se a máquina já foi atacada

A Alpine orienta checar /var/log/messages por linhas sshd com Accepted password para contas que não têm senha cadastrada, como alpine, root ou qualquer usuário só-chave. Vale também revisar uso recente de doas, usuários criados nos últimos dias, arquivos modificados e chaves adicionadas em authorized_keys.

Se não for possível descartar um login indevido num servidor exposto, a recomendação é tratar a máquina como comprometida e seguir o processo de resposta a incidente que já estiver em uso na equipe.

O que muda para quem mantém infraestrutura

O ponto prático aqui não é só rodar apk upgrade: é entender que a combinação de contas sem senha (comum em setups só-chave, bem recomendados como boa prática) com qualquer conta de senha cadastrada no mesmo host é o gatilho. Equipes que usam Alpine como base de imagem para servidores com sshd ativo, incluindo imagens tiny-cloud mais antigas, devem auditar hoje quais máquinas têm essa combinação, não só aplicar o patch e seguir em frente.

Vale lembrar que o patch cobre o pacote openssh-server nativo do Alpine; quem usa openssh-server-pam com UsePAM yes nunca esteve na rota de exploração, e trocar para esse modo é uma alternativa de mitigação permanente, além de desligar PasswordAuthentication.

Fonte: Hacker News