Falha crítica no OpenSSH afeta Alpine Linux; veja correção

Uma falha crítica no OpenSSH colocou servidores baseados em Alpine Linux e outras distribuições que utilizam a biblioteca musl libc em alerta. A vulnerabilidade permite contornar a autenticação SSH e obter acesso a contas que não possuem uma senha válida configurada, mesmo quando a administração acredita que esses usuários estão protegidos pelo uso exclusivo de chaves públicas. O problema pode ser explorado remotamente mediante o envio de uma senha especialmente longa, sem necessidade de conhecer a credencial legítima.

A gravidade do cenário levou a equipe responsável pelo OpenSSH a disponibilizar uma atualização emergencial, identificada como OpenSSH 10.6p2, em 5 de novembro de 2026. O projeto Alpine Linux também publicou pacotes corrigidos para suas diferentes versões, incluindo ramificações antigas. A correção é especialmente importante para administradores de servidores, ambientes em nuvem, infraestruturas de contêineres com acesso SSH e sistemas Linux minimalistas.

O detalhe mais preocupante é que a vulnerabilidade não depende necessariamente de uma senha fraca ou de uma configuração evidentemente insegura. Ela explora uma interação inesperada entre o mecanismo de autenticação do servidor SSH e o comportamento da função crypt() da musl libc. Neste artigo, você entenderá como acontece o bypass, quais configurações deixam uma máquina exposta e como atualizar ou proteger imediatamente seus servidores.

Como funciona a falha crítica no OpenSSH com musl libc

A vulnerabilidade, conhecida pela comunidade como ssh-hole, está relacionada à maneira como o sshd, processo responsável pelo servidor OpenSSH, verifica senhas em sistemas Linux compilados sem suporte ao PAM (Pluggable Authentication Modules).

O PAM funciona como uma camada intermediária de autenticação, permitindo que diferentes mecanismos e políticas sejam utilizados para validar credenciais. Quando o OpenSSH funciona sem essa integração, ele pode recorrer diretamente à função crypt(), disponibilizada pela biblioteca C do sistema operacional, para calcular e comparar hashes de senhas.

É justamente nessa interação que surge o problema.

A distribuição Alpine Linux utiliza a musl libc como biblioteca C padrão, em vez da glibc encontrada em distribuições como Ubuntu e Debian. Embora a musl seja conhecida por sua implementação compacta e eficiente, seu comportamento diante de determinadas entradas longas provoca uma condição que o código vulnerável do OpenSSH não tratava adequadamente.

Entendendo o mecanismo de hash e o empréstimo de salt

Para compreender a exploração, é necessário observar como o Linux armazena informações de autenticação.

Normalmente, os hashes das senhas ficam registrados em /etc/shadow. Entre os formatos utilizados estão SHA-256 ($5$) e SHA-512 ($6$), que incluem informações de salt, um valor utilizado durante o processo de geração do hash para dificultar ataques baseados em tabelas pré-computadas.

O problema aparece quando o servidor tenta autenticar uma conta cujo campo de senha contém apenas um asterisco (*). Essa representação não corresponde a um hash válido de senha e é frequentemente utilizada em contas destinadas à autenticação por chaves SSH.

Uma proteção histórica relacionada ao CVE-2016-6210 fez com que o OpenSSH utilizasse o salt de outra conta quando encontrava um campo de senha curto demais para fornecer essas informações. A intenção era preservar o comportamento de segurança esperado durante a verificação de credenciais.

Entretanto, em determinadas configurações, essa estratégia cria uma situação perigosa: o resultado produzido pela função de hash pode acabar sendo comparado diretamente com o conteúdo armazenado no campo da conta sem senha.

O limite de 256 bytes e o retorno inesperado da função

A musl libc possui um limite de 256 bytes para a senha recebida pela função crypt(). Quando uma entrada ultrapassa esse tamanho, a função retorna um asterisco (*) como indicador de erro.

Esse retorno é o elemento central da exploração.

Considere uma conta cujo campo de senha armazenado contém exatamente *. Se o atacante enviar uma senha com comprimento superior ao limite aceito pela musl, a função poderá devolver o mesmo caractere utilizado no campo da conta.

O código vulnerável não distinguia corretamente o retorno de erro de um resultado válido de autenticação. Consequentemente, a comparação poderia indicar uma correspondência e permitir o acesso sem que o atacante conhecesse a senha original.

Na prática, senhas entre 257 e 1024 bytes podem acionar essa condição dentro dos limites de processamento envolvidos na vulnerabilidade.

A correção do OpenSSH 10.6p2 modifica a verificação para rejeitar adequadamente esse tipo de resultado inválido, impedindo que um indicador de erro seja interpretado como um hash legítimo.

Sistemas vulneráveis e condições para exploração

Apesar da gravidade, a vulnerabilidade não afeta indiscriminadamente todos os servidores Linux que utilizam OpenSSH. A exploração depende da combinação de configurações específicas.

De acordo com o alerta de segurança do Alpine Linux, quatro condições precisam estar presentes:

1. OpenSSH compilado sem PAM: o pacote openssh-server padrão do Alpine utiliza essa configuração. O pacote openssh-server-pam também pode estar vulnerável quando executado com UsePAM no.
2. Autenticação por senha habilitada: a opção PasswordAuthentication precisa estar configurada como yes.
3. Existência de contas com campo de senha *: usuários destinados à autenticação exclusiva por chaves públicas podem apresentar essa configuração.
4. Existência de outra conta local com hash de senha $5$ ou $6$: essa conta fornece as informações necessárias para o mecanismo de empréstimo de salt.

A combinação desses elementos permite que um invasor com acesso à porta SSH tente autenticar-se como uma conta vulnerável utilizando uma senha longa especialmente preparada.

É importante distinguir contas com * de contas bloqueadas com ! no arquivo /etc/shadow. Esses valores não são equivalentes. Contas com ! estão bloqueadas para autenticação e não devem ser confundidas com os usuários afetados pelo comportamento descrito.

O risco adicional das imagens de nuvem e do usuário alpine

Um cenário particularmente preocupante envolve as imagens oficiais tiny-cloud do Alpine Linux.

Determinadas versões dessas imagens disponibilizam o usuário alpine com um campo de senha representado por * e permissões de elevação por meio do doas. Isso pode criar uma combinação perigosa quando as demais condições de exploração estão presentes.

O risco aumenta porque o invasor não precisa necessariamente obter acesso direto à conta root. Se conseguir autenticar-se como alpine e utilizar as permissões disponíveis no doas, poderá alcançar privilégios administrativos.

A configuração padrão de PermitRootLogin prohibit-password oferece proteção adicional contra o login direto de root por senha, mas não impede que outra conta vulnerável seja utilizada como caminho para elevar privilégios.

Administradores também devem observar outros ecossistemas que utilizam musl libc, especialmente OpenWrt, Buildroot e Yocto.

Isso não significa que todas essas plataformas estejam automaticamente vulneráveis. É necessário verificar como o OpenSSH foi compilado, se o PAM está habilitado e quais políticas de autenticação foram aplicadas. No caso do OpenWrt, o servidor Dropbear é utilizado por padrão, portanto a presença de musl libc, isoladamente, não significa exposição a essa falha específica do OpenSSH.

Como aplicar a correção e proteger o servidor imediatamente

A principal recomendação é atualizar o OpenSSH para uma versão corrigida e reiniciar o serviço SSH. Apenas instalar os pacotes novos não é suficiente, pois o processo sshd que já está em execução pode continuar utilizando o código vulnerável.

1. Atualize os pacotes do Alpine Linux

Em servidores Alpine, execute os seguintes comandos com privilégios administrativos:

apk upgrade -U -a

O comando atualiza os índices dos repositórios e aplica as atualizações disponíveis para os pacotes instalados.

A correção foi disponibilizada para diferentes ramificações do Alpine, incluindo versões anteriores à mais recente. Portanto, não é necessário migrar imediatamente toda a infraestrutura para outra versão da distribuição para receber o reparo, desde que o repositório da respectiva ramificação disponibilize o pacote corrigido.

Depois da atualização, verifique a versão instalada:

apk info -v openssh

Também é importante conferir se o pacote corresponde à revisão corrigida da sua versão do Alpine, em vez de considerar apenas o número principal do OpenSSH.

2. Reinicie obrigatoriamente o serviço SSH

Após atualizar os pacotes, reinicie o servidor SSH:

rc-service sshd restart

Essa etapa é indispensável. Sem o reinício, o processo antigo pode permanecer ativo na memória e continuar permitindo a exploração, mesmo depois da instalação do pacote corrigido.

Antes de executar mudanças de autenticação remotamente, mantenha uma sessão administrativa aberta e teste uma segunda conexão. Isso reduz o risco de perder o acesso ao servidor por causa de uma configuração incorreta.

3. Desabilite temporariamente a autenticação por senha

Se não for possível atualizar imediatamente, a medida emergencial recomendada é desabilitar a autenticação por senha.

Edite o arquivo:

vi /etc/ssh/sshd_config

Localize a diretiva PasswordAuthentication e configure:

PasswordAuthentication no

Salve o arquivo e reinicie o serviço:

rc-service sshd restart

Essa configuração impede a exploração pela modalidade de autenticação afetada. Entretanto, é necessário confirmar previamente que as chaves públicas estão funcionando e que os administradores conseguem acessar o servidor sem depender de senhas.

Para verificar a configuração efetiva do servidor, utilize:

sshd -T | grep -i passwordauthentication

O resultado esperado é:

passwordauthentication no

Atenção: arquivos adicionais em /etc/ssh/sshd_config.d/ e regras condicionais podem influenciar a configuração efetiva. Por isso, a verificação com sshd -T é mais confiável do que simplesmente procurar a diretiva no arquivo principal.

4. Audite possíveis invasões anteriores

A atualização corrige a vulnerabilidade, mas não elimina eventuais acessos indevidos ocorridos antes da instalação do patch.

Administradores devem verificar os registros de autenticação, especialmente em máquinas que mantiveram o SSH exposto à internet.

No Alpine Linux, examine o arquivo:

grep "Accepted password for" /var/log/messages

Procure registros de autenticação por senha em contas que deveriam aceitar exclusivamente chaves públicas, especialmente usuários como alpine, root e outras contas administrativas sem senha válida.

Também é recomendável investigar:

• Utilização do doas: procure execuções suspeitas e tentativas de elevação de privilégios.
• Novos usuários: confira contas criadas recentemente e alterações em /etc/passwd e /etc/shadow.
• Chaves SSH: examine arquivos authorized_keys em busca de chaves desconhecidas.
• Persistência: verifique serviços, tarefas agendadas e arquivos modificados recentemente.
• Acessos administrativos: correlacione os horários dos logins suspeitos com outras atividades registradas no sistema.

A ausência de registros suspeitos não comprova, isoladamente, que o servidor nunca foi comprometido. Caso exista evidência de acesso não autorizado, trate a máquina como potencialmente comprometida e siga um procedimento de resposta a incidentes, incluindo rotação de credenciais e investigação da persistência.

Por que o patch foi lançado sem embargo prolongado?

Um dos aspectos mais interessantes desse incidente está na decisão da equipe do OpenSSH de reduzir o intervalo entre a identificação da vulnerabilidade e a publicação da correção.

Tradicionalmente, vulnerabilidades graves podem passar por períodos de embargo. Durante esse intervalo, desenvolvedores e distribuidores trabalham para preparar atualizações antes que os detalhes técnicos sejam divulgados publicamente.

Entretanto, essa estratégia enfrenta um desafio crescente: agentes de inteligência artificial capazes de analisar código e redescobrir vulnerabilidades em pouco tempo.

Nas notas de lançamento do OpenSSH 10.6p2, a equipe reconheceu que recebeu um número expressivo de relatórios de segurança produzidos por modelos de IA ou com auxílio dessas ferramentas. Nem todos os apontamentos representam problemas exploráveis em cenários reais, mas os desenvolvedores consideram essas contribuições importantes quando acompanhadas de análise humana, testes e propostas concretas de correção.

O posicionamento foi ainda mais direto no comunicado de lançamento. A equipe relatou casos em que vulnerabilidades identificadas por ferramentas de IA foram descobertas independentemente por outros agentes em poucas horas.

Segundo os responsáveis pelo projeto, embargos prolongados podem se tornar perigosos quando oferecem aos atacantes tempo suficiente para redescobrir falhas antes que os administradores tenham acesso às correções.

Essa decisão representa uma mudança importante na dinâmica da segurança de código aberto. A inteligência artificial não substitui a análise de especialistas, mas aumenta a velocidade com que problemas podem ser encontrados, reproduzidos e investigados.

No caso dessa vulnerabilidade, a equipe optou por disponibilizar rapidamente uma solução, mesmo considerando que a origem do problema estava no comportamento da biblioteca musl libc, e não propriamente em uma falha interna de implementação do SSH.

A segurança do SSH exige atenção além das chaves públicas

A vulnerabilidade demonstra que utilizar autenticação por chaves públicas não garante, por si só, que todas as demais modalidades de acesso estejam protegidas. Uma configuração aparentemente segura pode continuar exposta quando a autenticação por senha permanece habilitada e outras condições específicas estão presentes.

Para administradores de Alpine Linux, a prioridade deve ser verificar os servidores expostos, atualizar o OpenSSH, reiniciar o serviço e investigar possíveis acessos indevidos. Ambientes baseados em imagens de nuvem também precisam passar por auditoria, principalmente quando utilizam contas administrativas predefinidas.

A decisão do projeto OpenSSH de acelerar a divulgação da correção também reforça uma realidade: com ferramentas de IA aumentando a capacidade de descoberta de vulnerabilidades, manter sistemas atualizados deixou de ser apenas uma boa prática e passou a ser uma necessidade operacional ainda mais urgente.