SSHole — uma vulnerabilidade que permite a conexão via SSH sem senha em sistemas com Musl

Os desenvolvedores do OpenSSH publicaram uma atualização de emergência, o OpenSSH 10.6p2, que inclui proteções contra uma vulnerabilidade crítica (CVE não designado) codinome "SSHole", permitindo contornar a autenticação. Em sistemas com a biblioteca Musl, a vulnerabilidade permite conectar-se a um usuário sem senha, inserindo qualquer senha que contenha mais de 256 caracteres. O problema afeta distribuições Linux que usam a biblioteca padrão musl, mas não utilizam PAM (Módulos de Autenticação Pluggable), como OpenWRT, Alpine, Buildroot e Yocto. Um risco adicional é que, frequentemente, o login por senha é bloqueado para o usuário root, permitindo que qualquer pessoa se conecte remotamente com privilégios de administrador.

O problema que leva à vulnerabilidade não está no código do OpenSSH, mas é explorado através do sshd. Dada a gravidade do problema, na versão OpenSSH 10.6p2 foi proposta uma solução alternativa para bloquear a vulnerabilidade. Foi recomendado aos proprietários de sistemas afetados que não esperassem por atualizações, mas imediatamente desativassem a autenticação por senha usando o parâmetro "PasswordAuthentication no" em /etc/ssh/sshd_config ou desativassem completamente o SSH.

O problema não se manifesta em sistemas diferentes do Linux e em ambientes Linux baseados em glibc, bem como em sistemas que usam PAM para autenticação por senha. A correção já está disponível no Alpine e no OpenWRT.

A vulnerabilidade está relacionada à interação incorreta entre o OpenSSH e a função crypt() da musl. Para proteger contra a determinação da existência de usuários através da análise das diferenças nos tempos de processamento das solicitações, desde 2016 o OpenSSH utiliza um procedimento padrão para verificar contas sem senha: ele chama a função "crypt(senha fornecida, salt)" com o salt de outro usuário que possui um hash de senha válido, e em seguida compara o hash retornado pela função crypt com o valor do campo que contém o hash da senha.

No entanto, na musl, a função crypt() para hashes SHA-512 retorna o caractere "*" se o comprimento da senha fornecida exceder 256 bytes (limite introduzido em 2012 para proteção contra ataques DoS, pois a transmissão de valores grandes cria uma carga maior na CPU). O mesmo caractere é utilizado no campo com o hash da senha em "/etc/shadow" para indicar contas para as quais a autenticação por senha está bloqueada.

Como resultado, um atacante que consegue se conectar ao servidor SSH pode acessar qualquer conta cujo campo de senha em «/etc/shadow» contenha o símbolo «*», enviando uma string com comprimento de 257 a 1024 bytes. O problema abrange várias imagens Docker existentes construídas com Alpine Linux, assim como as imagens padrão do Alpine para sistemas em nuvem AWS e Azure, onde, no usuário root, o hash da senha foi substituído pelo símbolo «*».

É notável que, inicialmente, nas imagens Docker oficiais que utilizam Alpine, desde 2015, a senha root era deixada em branco e após a descoberta desse fato, o hash da senha foi substituído pelo símbolo «!». No entanto, sua presença bloqueava o acesso via chaves SSH, portanto, desde 2022, o símbolo para bloquear o acesso por senha foi alterado para «*».

Fonte: opennet.ru