OpenSSH 10.6p2: falha sshole e o que a PME faz hoje
Um erro que passou quase dez anos escondido no OpenSSH, o programa que protege o acesso remoto a servidores Linux, ganhou nome e correção nesta semana. Apelidada de sshole, a falha permite que uma senha com 257 a 1.024 caracteres abra contas que nunca deveriam aceitar senha, inclusive o root. A correção veio na versão 10.6p2, lançada na quinta-feira (5). O caso é restrito, mas atinge uma base que muita PME usa sem saber: contêineres e servidores em nuvem baseados em Alpine Linux.
O que aconteceu
Segundo o The Register, a vulnerabilidade foi descoberta pelo pesquisador Özgün Kültekin e só funciona em sistemas Linux que usam a biblioteca musl libc, e não a biblioteca GNU. Além disso, o servidor SSH precisa rodar sem PAM (módulos de autenticação) e com autenticação por senha habilitada.
A explicação técnica, de acordo com a mesma reportagem, é uma sequência de decisões antigas. Contas que não devem aceitar senha guardam um asterisco no campo de senha. Quando a função de cálculo de hash do musl não consegue processar uma senha maior que 256 bytes, ela devolve justamente um asterisco. O OpenSSH, desde 2016, calcula um hash fictício para usuários inexistentes (para não revelar quais nomes de conta existem). Na combinação, o resultado "asterisco" pode ser aceito como se fosse a senha correta.
O texto do TabNews, que resume a mesma matéria, acrescenta o requisito de que pelo menos outra conta tenha um hash de senha válido. O The Register informa ainda que o login direto como root continua sujeito à configuração do OpenSSH, e que não há indício de que sistemas vulneráveis tenham sido explorados.
O Linuxiac, que cobriu o anúncio do projeto, descreve a 10.6p2 como atualização urgente e diz que os desenvolvedores implementaram uma solução de contorno no sshd, já que a causa está fora do OpenSSH. O mesmo texto traz outra mudança: o projeto afirma que vai publicar correções de segurança com mais frequência, por causa do aumento de relatos de vulnerabilidades feitos com auxílio de inteligência artificial.
Cinco cartões listando as condições simultâneas para a falha sshole no OpenSSH: musl libc, sem PAM, senha ativada, conta com asterisco e outra conta com hash válido.
Por que isso importa para a sua empresa
O The Register destaca que o musl não é raridade: é a biblioteca padrão do Alpine Linux, que tem imagens oficiais na AWS e na Azure, e é comum em sistemas embarcados. Alpine é também uma escolha frequente em contêineres Docker, justamente por ser pequeno. Por isso, quem terceirizou a infraestrutura pode ter um servidor afetado sem nunca ter ouvido falar de musl.
O risco não é igual para todos. A falha exige cinco condições ao mesmo tempo, e a maioria dos servidores comerciais que usam Debian ou Ubuntu fica fora do cenário. Ainda assim, o que está em jogo é acesso administrativo ao servidor, onde costumam ficar banco de dados, notas fiscais, backups e o próprio sistema de vendas.
Um exemplo hipotético ajuda a dimensionar. Imagine uma empresa de software com 8 servidores e contêineres. Ela confere e descobre que 3 usam Alpine. Desses, 1 roda o SSH sem PAM e com senha ativada. A exposição real é de 1 em 8, ou 12,5% do parque. Parece pouco, mas basta uma máquina assim para o invasor chegar ao restante da rede interna.
| Etapa do inventário (hipotético) | Máquinas | % do parque |
|---|
| Total de servidores e contêineres | 8 | 100% |
| Usam Alpine (musl) | 3 | 37,5% |
| Alpine, sem PAM e com senha ativada | 1 | 12,5% |
Há um detalhe que merece atenção: o ataque usa uma senha longa demais, o oposto do que se recomenda para proteger contas. Nesse caso, o que protege é não aceitar senha. Se sua equipe ainda reutiliza senhas fracas em outros sistemas, vale conferir o guia sobre como criar uma senha segura e usar o gerador de senhas para contas que realmente precisam delas.
O que fazer agora
- Pergunte a quem administra seus servidores: alguma máquina ou contêiner usa Alpine Linux ou outra distribuição com musl? Sem essa resposta, o resto da lista não se aplica.
- Atualize o OpenSSH para a 10.6p2 ou superior assim que o pacote da distribuição estiver disponível, e confirme a versão instalada em vez de presumir.
- Desative a senha no SSH antes de esperar o pacote. Se não der para atualizar hoje, configure
PasswordAuthentication no e reinicie o serviço, como orienta o The Register. Faça isso depois de confirmar que todos os acessos legítimos usam chave, para não trancar a própria equipe fora.
- Prefira chaves SSH a senhas em todo acesso administrativo. É uma decisão que reduz o risco de várias falhas parecidas, não só desta.
- Verifique sinais de uso indevido. O pesquisador publicou um comando que mostra se contas sem senha aceitaram algum login recente. Peça ao responsável técnico para rodá-lo nas máquinas com musl.
- Acompanhe os avisos do projeto com mais frequência. Se o OpenSSH vai soltar correções fora do calendário, a rotina de atualização do servidor precisa ser mensal, no mínimo, e não anual.
Se a sua infraestrutura é toda gerenciada por um provedor ou agência, a ordem é perguntar antes de agir: peça um parecer curto por escrito sobre a exposição à falha. É mais barato do que descobrir um acesso indevido depois, e o custo de uma interrupção entra direto no fluxo de caixa projetado.
O que ainda não sabemos
- Quantas empresas brasileiras usam servidores com a combinação exata de condições. Nenhuma das fontes lidas traz esse número.
- Se houve tentativas reais de exploração. O The Register diz que não há indício até agora, mas isso pode mudar com a divulgação pública do método.
- O cronograma em que cada distribuição, em especial o Alpine, vai liberar o pacote corrigido. Confira o aviso oficial da distribuição que você usa.
- Detalhes de classificação formal (como número de identificação da falha). As matérias lidas não trazem essa informação de forma consistente, e por isso ela não entra neste texto.
Este conteúdo é informativo e não substitui a análise de um profissional de segurança da informação.
Fontes consultadas
Mais artigos no blog