OpenSSH 10.6p2 corrige falha crítica que permite contornar autenticação por senha no Linux

O projeto OpenSSH lançou a versão 10.6p2 do Portable OpenSSH para solucionar uma vulnerabilidade grave no processo de autenticação por senha. O problema pode permitir que um invasor obtenha acesso a determinadas contas sem conhecer suas senhas, desde que o servidor utilize uma combinação específica de biblioteca de sistema e configurações de autenticação.

A falha afeta principalmente instalações Linux que utilizam a biblioteca musl libc e executam o servidor OpenSSH sem suporte ao PAM (Pluggable Authentication Modules). O Alpine Linux é um exemplo importante desse cenário, pois seu pacote padrão openssh-server é compilado sem PAM.

A atualização também reúne correções que já haviam sido incorporadas ao ramo estável do OpenSSH 10.6. Entre elas estão melhorias no suporte a assinaturas híbridas pós-quânticas, ajustes no consumo de CPU e correções de compatibilidade com diferentes sistemas operacionais.

Como funciona a falha de autenticação do OpenSSH?

O problema está relacionado à maneira como o servidor SSH verifica senhas em sistemas que utilizam musl libc e não contam com autenticação via PAM.

Quando o PAM não está habilitado, o sshd pode utilizar a função crypt() da biblioteca C para transformar a senha apresentada pelo usuário em um hash e compará-lo ao valor armazenado no sistema. Esse procedimento permite verificar se a credencial informada corresponde à senha cadastrada.

Entretanto, existe uma situação específica envolvendo contas cujo campo de senha contém apenas um asterisco (*). Esse valor pode aparecer em contas sem senha definida, incluindo usuários configurados para autenticação exclusivamente por chave SSH.

O problema surge quando o OpenSSH tenta verificar uma senha muito longa utilizando a implementação da função crypt() presente na musl. Para entradas superiores a 256 bytes, essa biblioteca retorna o caractere * como indicação de erro.

Em determinadas condições, o OpenSSH pode acabar comparando esse retorno com o campo de senha da conta. Como os dois valores são iguais, a verificação pode ser interpretada incorretamente como uma autenticação válida.

Na prática, um invasor que consiga alcançar a porta SSH do servidor pode explorar esse comportamento para entrar em uma conta que não possui uma senha convencional configurada.

Quais condições são necessárias para explorar a vulnerabilidade?

A falha não afeta indiscriminadamente todos os servidores OpenSSH. A exploração depende da combinação de vários fatores:

• O sistema precisa utilizar Linux com a biblioteca musl libc.
• O servidor OpenSSH deve estar compilado e configurado sem utilizar PAM para autenticação.
• A opção PasswordAuthentication precisa estar habilitada.
• Deve existir uma conta cujo campo de senha esteja configurado como *.
• Pelo menos outra conta local precisa possuir um hash de senha nos formatos $5$ ou $6$.

De acordo com o alerta publicado pelo projeto Alpine Linux, o invasor precisa conhecer o nome de uma conta vulnerável e enviar uma senha com tamanho entre 257 e 1.024 bytes. Nessas condições, a autenticação pode ser aceita sem que a senha verdadeira seja conhecida.

Um detalhe importante é que contas sem senha definida não são necessariamente um sinal de configuração incorreta. Usuários preparados para acessar sistemas exclusivamente por chaves SSH podem apresentar esse tipo de campo. Portanto, a vulnerabilidade pode atingir ambientes que utilizam práticas legítimas de administração.

O problema também pode afetar imagens de servidores em nuvem e instalações automatizadas, dependendo das contas criadas e das opções de autenticação configuradas.

Alpine Linux está entre os sistemas afetados

O Alpine Linux foi destacado porque utiliza musl libc como biblioteca C padrão e oferece um pacote OpenSSH que não utiliza PAM por padrão.

O alerta de segurança da distribuição confirma que diferentes versões foram afetadas, incluindo as séries 3.16 a 3.24 e o ramo Edge. A equipe do Alpine também preparou pacotes corrigidos para versões anteriores, inclusive algumas que já não recebem atualizações regulares.

É importante diferenciar os ambientes vulneráveis daqueles que apenas utilizam Alpine Linux. Um sistema que não executa o serviço sshd, por exemplo, não está exposto a esse vetor de ataque. Da mesma forma, instalações com autenticação por senha desativada ou que utilizam PAM corretamente não são afetadas pelo cenário descrito.

O OpenSSH também informa que a vulnerabilidade não está presente em sistemas que utilizam glibc, em sistemas operacionais que não são Linux ou em instalações Linux que utilizam PAM para autenticação por senha.

Isso não significa que esses ambientes devam ignorar atualizações de segurança, mas ajuda administradores a identificar onde a correção emergencial é mais urgente.

Como corrigir o problema

A solução recomendada é instalar o OpenSSH 10.6p2 ou uma atualização equivalente disponibilizada pelo mantenedor da distribuição.

Administradores devem verificar a versão efetivamente instalada nos servidores e consultar os avisos de segurança do sistema utilizado. Distribuições que mantêm versões próprias podem incorporar a correção sem necessariamente adotar o número 10.6p2.

No Alpine Linux, por exemplo, os pacotes corrigidos foram disponibilizados para diferentes ramos. A atualização pode ser realizada com:

apk upgrade -U -a

Depois de atualizar os pacotes, é necessário reiniciar o serviço SSH:

rc-service sshd restart

Esse passo é particularmente importante porque a instalação de um pacote atualizado não substitui automaticamente o processo sshd que já está em execução. Se o serviço continuar utilizando o binário antigo, o sistema poderá permanecer vulnerável mesmo depois da atualização.

Medida temporária para quem ainda não pode atualizar

Se não for possível instalar imediatamente uma versão corrigida, o projeto Alpine recomenda desabilitar a autenticação por senha no servidor SSH.

A opção correspondente é:

PasswordAuthentication no

Ela deve ser definida na configuração do servidor, normalmente no arquivo /etc/ssh/sshd_config ou em um arquivo complementar incluído por ele.

Antes de aplicar a mudança, administradores devem confirmar que conseguem acessar o servidor por meio de chaves SSH. Também é recomendável manter a sessão atual aberta enquanto um novo acesso é testado.

Depois de alterar a configuração, é necessário validar os parâmetros e reiniciar o serviço. No Alpine Linux, por exemplo, a verificação pode ser feita com:

sshd -t

E o serviço pode ser reiniciado com:

rc-service sshd restart

Desativar a autenticação por senha é uma medida de mitigação, não um substituto permanente para a atualização. A recomendação é instalar o pacote corrigido assim que possível.

OpenSSH 10.6p2 também traz outras melhorias

Embora a correção de segurança seja o principal motivo do lançamento, a versão 10.6p2 inclui outros ajustes importantes.

Um deles habilita o algoritmo híbrido de assinatura pós-quântica ssh-mldsa44-ed25519 como um algoritmo permitido para assinaturas de autoridades certificadoras (CA).

Esse mecanismo combina componentes criptográficos diferentes em uma abordagem híbrida. A intenção é permitir o uso conjunto de técnicas tradicionais e pós-quânticas, preparando a infraestrutura de autenticação SSH para a evolução dos riscos associados aos computadores quânticos.

Outra correção resolve um problema que podia provocar um breve aumento desnecessário no uso da CPU quando a opção ChannelTimeout estava habilitada. O comportamento durava menos de um segundo, mas poderia gerar atividade adicional durante determinadas operações.

A atualização também corrige situações em que os programas ssh, ssh-add e ssh-keygen apresentavam comportamentos inesperados quando recebiam os sinais SIGINT ou SIGQUIT durante a leitura de uma senha ou frase secreta.

Esses sinais são utilizados para interromper processos. O ajuste torna mais previsível o comportamento das ferramentas quando o usuário cancela uma operação de autenticação.

Melhorias de compatibilidade e portabilidade

O OpenSSH 10.6p2 inclui ainda correções para diferentes plataformas e ambientes.

Entre elas está a solução de um problema de compilação em sistemas antigos que utilizam a definição SKIP_PRIVDROP. Também foi corrigida a detecção de localidades do Azerbaijão.

Outra mudança melhora a criação de sockets do agente SSH em plataformas que não oferecem a chamada de sistema openat(). Esse recurso é importante para o funcionamento do ssh-agent, que gerencia chaves privadas utilizadas durante conexões SSH.

O servidor também recebeu uma alteração relacionada ao sandbox baseado em seccomp. A chamada de sistema restart_syscall() passou a ser permitida nesse ambiente restrito, corrigindo um problema de compatibilidade.

Essas mudanças não representam novas funcionalidades diretamente visíveis para a maioria dos usuários, mas ajudam a manter o OpenSSH funcional em uma variedade maior de sistemas.

Projeto OpenSSH pretende publicar correções de segurança com mais frequência

Outro ponto relevante do anúncio é a mudança na estratégia de manutenção do projeto.

Os desenvolvedores informaram que têm recebido um número crescente de relatórios de segurança produzidos ou auxiliados por ferramentas de inteligência artificial. Muitos desses relatos não representam problemas exploráveis em cenários reais, mas outros identificam vulnerabilidades legítimas.

A equipe também observou situações em que uma falha inicialmente encontrada por ferramentas de IA foi descoberta independentemente por outro pesquisador. Isso indica que vulnerabilidades ainda não divulgadas podem também ser identificadas por agentes mal-intencionados.

Diante desse cenário, o projeto pretende publicar atualizações de segurança com maior frequência, em vez de concentrar todas as correções no próximo lançamento planejado. A intenção é reduzir o intervalo entre a identificação de um problema e a disponibilização de uma solução para os usuários.

O anúncio também mantém o aviso de descontinuação futura da opção -R do comando scp, utilizada para realizar cópias diretamente entre dois hosts remotos por meio da execução do scp em um dos servidores. A opção já gera um aviso de descontinuação desde o OpenSSH 10.6 e poderá ser ignorada em uma versão futura.

Atualização é especialmente importante para administradores Linux

O OpenSSH 10.6p2 é uma atualização de segurança prioritária para administradores que utilizam Linux com musl libc e autenticação por senha sem PAM. A falha permite um cenário particularmente preocupante: o acesso a determinadas contas sem a necessidade de conhecer suas credenciais.

Quem administra servidores Alpine Linux deve verificar imediatamente a versão do pacote instalado, aplicar a atualização disponibilizada pela distribuição e reiniciar o serviço SSH. Caso não seja possível atualizar de imediato, a autenticação por senha deve ser desativada como medida temporária.

Para os demais usuários, a versão também oferece correções de estabilidade, melhorias de compatibilidade e suporte a um algoritmo híbrido de assinatura pós-quântica. Mesmo sendo um lançamento pontual, o OpenSSH 10.6p2 demonstra a importância de manter atualizados os componentes responsáveis pelo acesso remoto e pela administração de sistemas.