Falha no OpenSSH: inventarie a configuração, não apenas a distribuição

O OpenSSH publicou a versão 10.6p2 para corrigir um desvio de autenticação classificado como crítico em determinadas configurações com musl, e o Alpine também distribuiu pacotes corrigidos.[1] A notícia não relatava exploração observada nem CVE atribuído no momento da publicação.[1] O trabalho de engenharia começa por descobrir quais servidores realmente satisfazem as condições, não por declarar todo ambiente Alpine comprometido.

O que muda para quem desenvolve

O cenário descrito combina verificação de senha sem PAM, autenticação por senha habilitada, uma conta com campo de senha * e outra conta local com hash iniciado por $5$ ou $6$.[1] Nessa interação, um marcador de erro retornado pela função de hash pode coincidir com o valor armazenado e ser interpretado como autenticação válida.[1]

A implicação para quem mantém imagens e provisionamento é importante: uma decisão aparentemente defensiva precisa ser avaliada junto das demais configurações. No caso relatado, contas destinadas a acesso exclusivamente por chave também podem entrar no cenário vulnerável.[1] A intenção do administrador não substitui a configuração efetiva.

O pacote padrão openssh-server do Alpine não usa PAM, mas sistemas com glibc, sistemas não Linux e verificação de senha por PAM ficam fora do escopo descrito.[1] Portanto, um inventário útil deve relacionar serviço exposto, biblioteca, método de autenticação e contas, em vez de apenas procurar o nome da distribuição.

Como aplicar

Monte uma lista das máquinas que executam sshd e classifique a exposição antes de priorizar a atualização. Registre também quem pode elevar privilégios depois de entrar. A matéria destaca que algumas imagens tiny-cloud permitem doas sem senha ao usuário alpine, ampliando o impacto de uma conta comum comprometida.[1]

A correção recomendada inclui atualizar o pacote e reiniciar o serviço, pois instalar a atualização não reinicia automaticamente o sshd existente.[1] Como critério de encerramento, exija evidência do pacote corrigido, do novo processo e de um acesso administrativo validado.

Se a contenção escolhida for desabilitar senha, confirme antes o acesso por chave e mantenha uma sessão aberta; a orientação também pede atenção a exceções em blocos Match.[1] Trate essa mudança como operação com possibilidade de bloqueio, com responsável e caminho de recuperação definidos.

Cuidados e limites

Contêineres sem sshd, máquinas com PasswordAuthentication no e contas bloqueadas com ! não satisfazem o cenário relatado.[1] Isso evita campanhas de atualização mal direcionadas, mas não dispensa confirmar cada premissa.

Para investigação, a matéria recomenda procurar logins por senha em contas que não deveriam aceitá-la, uso de doas e alterações em usuários ou chaves autorizadas.[1] Corrigir a vulnerabilidade e determinar se houve acesso indevido são entregas diferentes. Não encerre a segunda apenas porque a primeira terminou.

Fonte

[1] Fonte: The Hacker News