Alpine Linux e OpenSSH: Perigo Máximo Corrigido!

UM SIMPLES ASTERISCO PODE DERRUBAR SEU SERVIDOR? O BUG DO OPENSSH NO LINUX QUE VOCÊ PRECISA CONHECER!

Olá, pessoal! Aqui é o Lucas Tech, e hoje a gente vai mergulhar de cabeça em um assunto que deixou a comunidade Linux em alerta máximo. Sabe aquele pesadelo em que um atacante consegue entrar no seu servidor sem muito esforço, como se estivesse passeando no parque? Pois é, algo muito parecido aconteceu com o Alpine Linux e algumas outras distros! Preparem-se, porque a coisa é séria e merece nossa atenção imediata.

A Treta Resumida: O que você precisa saber AGORA!

Pra começar, vamos direto ao ponto. A ZDNET deu a letra, e os principais pontos são:

Um bug bem antigo está afetando o Alpine Linux e algumas outras distribuições Linux.
A coisa é grave, tipo "pode dar muito ruim" para a segurança dos seus servidores.
Você PRECISA aplicar a correção (patch) o mais rápido possível e reiniciar o software afetado.

O Pesadelo do Servidor: SSH Abrindo Portas Para Quem Não Deve!

O cenário que nenhum administrador de sistemas quer viver é o seguinte: um atacante só precisa chegar na porta SSH (Secure Shell) do seu servidor — aquela conexão segura que usamos para acessar remotamente — e, bum, ele entra e toma conta de tudo. E foi exatamente isso que rolou com o Alpine Linux, uma distro bem popular e conhecida por ser leve e eficiente para servidores.

E como se não bastasse, isso aconteceu dias depois do Alpine ter se livrado de uma outra grande falha de segurança em sua implementação do GitLab! É tipo sair da chuva pra cair na goteira, sabe?

Como o Ataque Funciona: A Magia de um Único Asterisco

O engenheiro de segurança Gregory Bryant explicou super bem lá no LinkedIn dele:

"A maioria dos bypass de autenticação vem de cadeias lógicas complexas, mas a vulnerabilidade OpenSSH do Alpine Linux (CVE-2026-123158) se resume a um único caractere: *."

Pois é, um asterisco! Parece piada, mas não é. Se você usa Alpine Linux (ou outra distro baseada em musl — uma versão mais leve da biblioteca C padrão, o libc) com o pacote openssh-server padrão (sem módulos PAM – Pluggable Authentication Modules) e a autenticação por senha ativada, um atacante pode simplesmente enviar uma senha com um tamanho entre 257 e 1024 bytes e entrar em contas que deveriam estar desabilitadas por senha ou configuradas apenas para chave.

É isso. Simples assim.

A Diferença entre `musl` e `glibc`

Por trás dos panos, quando o OpenSSH é compilado sem o PAM, ele verifica senhas "hasheando" a tentativa de senha usando a função crypt() da biblioteca C e comparando o resultado com o campo de senha armazenado na conta. Até aí, tudo certo.

O problema é que, quando uma chave (ou, neste caso, uma senha muito longa) é maior que 256 bytes, a função crypt() do musl retorna o caractere * como um indicador de erro. E adivinha? Esse mesmo * é o que aparece no campo de senha para qualquer conta que não tem senha, como aquelas configuradas para usar apenas chave. Resultado: o "hash" bate, o login é bem-sucedido e o atacante entra!

Em sistemas Linux que usam o glibc (a maioria, como Debian, Ubuntu, Fedora, etc.), a função crypt() retornaria NULL em caso de erro, e o sshd (o servidor SSH) já rejeita isso. Por isso, essas distros não são afetadas.

Segundo o pessoal do *sshole (o grupo que descobriu a falha), esse é um "efeito colateral" que estava escondido desde 2016! Imagina só, um bug de oito anos esperando para ser descoberto.

Quem Está Exposto e Quem Está Seguro?

O Alpine Linux disse que todas as versões verificadas estão afetadas: da 3.21 à 3.24, a versão "edge" e também as branches mais antigas, da 3.16 à 3.20. Mas calma, não é qualquer sistema Alpine que está vulnerável. Para estar exposto, seu servidor precisa ter:

O pacote openssh-server compilado sem PAM, ou openssh-server-pam com UsePAM no.
A PasswordAuthentication configurada como yes (que é o padrão do OpenSSH).
Uma conta com * como campo de senha (como contas configuradas para chave), E outra conta com um hash de senha tipo 5 ou 6.

Em muitos casos, o usuário root não está diretamente exposto porque o PermitRootLogin prohibit-password do OpenSSH bloqueia. No entanto, se um atacante conseguir acessar uma conta que pode se tornar root (por exemplo, via doas), ele ainda pode chegar ao root.

As imagens tiny-cloud oficiais do Alpine, versões 3.18.11 até 3.24.3, são especialmente vulneráveis. Elas vêm com um usuário alpine com senha * e doas sem senha. Elas são seguras na primeira inicialização, mas se tornam exploráveis assim que qualquer hash de senha tipo 6 é criado na máquina (o que pode acontecer quando um administrador define uma senha ou quando dados do usuário adicionam um usuário com senha hasheada — ou seja, na prática, quase todas elas).

Quem não está afetado:

Containers que não rodam sshd.
Sistemas com autenticação por senha desabilitada.
Sistemas usando openssh-server-pam com UsePAM yes.
Contas bloqueadas (com ! no campo de senha).
Imagens de nuvem configuradas via cloud-init, que geralmente configura PasswordAuthentication no.

Outros sistemas que usam musl e podem estar vulneráveis incluem Adélie Linux, Void Linux, Sabotage Linux, OpenWrt (uma variante Android) e o Yocto Project (usado para criar distribuições Linux embarcadas). A Wind River, que produz a distro Linux embarcada comercial Wind River Linux, também está investigando o problema.

A Solução Chegou! Como Proteger Seu Servidor

A boa notícia é que o Alpine já agiu! Eles lançaram as versões 3.21.10, 3.22.8, 3.23.8 e 3.24.4 na quinta-feira, com a correção do OpenSSH entre as atualizações de segurança. Além disso, pacotes corrigidos foram publicados para todas as versões desde a 3.16.

O recém-lançado OpenSSH 10.6p2 também já evita o problema no sshd. As branches estáveis do Alpine já incluem um patch para o mesmo problema.

Como aplicar a correção:

Atualize seu Alpine: Execute o comando apk upgrade -U -a.
Reinicie o daemon SSH: Execute rc-service sshd restart. O Alpine frisou que atualizar o pacote não substitui o daemon em execução, então o restart é crucial!

Se, por algum motivo, você não puder atualizar imediatamente, uma alternativa é desativar a autenticação por senha. Para isso, edite a configuração do SSH (/etc/ssh/sshd_config ou similar) e defina:

PasswordAuthentication no

Depois, não se esqueça de reiniciar o sshd com rc-service sshd restart – e, claro, confirme antes que o login por chave está funcionando direitinho para você não ficar trancado para fora do seu próprio servidor!

Para verificar se houve um ataque, o Alpine aconselhou os administradores a procurar no arquivo /var/log/messages por linhas como "Accepted password for" que mencionem uma conta sem senha. Também é bom revisar o uso do doas (uma ferramenta tipo sudo do OpenBSD), usuários recém-criados, arquivos estranhos e chaves autorizadas. "Se você não conseguir descartar um login, trate a máquina como comprometida", disseram eles. Sei que não é a notícia que você queria para o seu fim de semana, mas é a realidade!

Minha Visão

É impressionante como um detalhe tão pequeno, um simples asterisco, pode se esconder por tanto tempo e causar um estrago tão grande. Isso nos lembra que, mesmo em sistemas que consideramos robustos e confiáveis como o Linux, a vigilância nunca é demais. A comunidade open source é incrível, mas até mesmo os melhores podem ter "pontos cegos". Essa descoberta ressalta a importância de auditorias contínuas e da colaboração para garantir a segurança de todos. É um lembrete de que a segurança não é um destino, mas uma jornada constante de adaptação e correção. Fica a lição de que precisamos estar sempre atentos, mesmo aos detalhes que parecem mais inofensivos!

E você, já verificou seus servidores? Qual sua opinião sobre a descoberta de bugs tão antigos em softwares tão usados? Deixa seu comentário aqui embaixo!

Referência: Matéria Original