Uma decisão tomada em 2012 pela biblioteca musl pode ter criado uma situação inesperada no OpenSSH: contas bloqueadas com o campo “*” no arquivo de senhas poderiam, em determinadas circunstâncias, aceitar uma senha incorreta. O problema passou anos sem ser identificado e foi corrigido em uma revisão de segurança do OpenSSH publicada em outubro de 2026, segundo o relato que reconstrói a sequência de mudanças.

A origem do asterisco remonta a 1980. No Unix, as senhas criptografadas eram armazenadas em /etc/passwd, um arquivo acessível a todos os usuários. Bill Joy colocou “*” no campo de senha da conta daemon, que não deveria permitir login. Como o caractere não corresponde ao resultado de uma senha criptografada, a conta ficava bloqueada. O campo seguinte trazia o nome “the devil himself”.

Com a adoção de /etc/shadow, as senhas passaram a ser guardadas em um arquivo separado. Em condições normais, o sistema aplica à senha digitada o algoritmo e o salt indicados no registro e compara o resultado com o valor armazenado. Se o campo contém apenas “*”, não há hash válido com o qual a senha possa coincidir.

A complicação surgiu na forma como algumas implementações lidavam com falhas. A especificação Single UNIX de 1997 prevê que crypt() retorne NULL quando não consegue calcular um hash. Programas que não verificam esse retorno podem falhar ao tentar compará-lo com o valor armazenado.

Em agosto de 2012, a musl, biblioteca padrão usada pelo Alpine Linux, mudou esse comportamento: em vez de retornar NULL, crypt() passou a devolver um caractere que não poderia corresponder a uma senha válida. O caractere escolhido foi “*”, o mesmo usado para bloquear contas. Vinte dias depois, ao implementar o suporte a SHA-512, a musl também limitou a entrada a 256 bytes, para evitar que senhas muito longas consumissem tempo excessivo de processamento. Entradas maiores falhavam e, novamente, podiam resultar em “*”.

A consequência apareceu no OpenSSH. Em 2016, uma correção para a CVE-2016-6210 buscou reduzir a diferença de tempo entre a resposta para um usuário inexistente e para um usuário válido. Para isso, o servidor passou a calcular um hash mesmo quando não havia uma senha real a verificar, usando o salt de outra conta. A resposta continuava sendo negativa, mas o processamento demorava um intervalo semelhante.

O caso problemático, porém, incluía usuários reais cujo campo de senha era “*”. Nessa situação, a falha de crypt() podia produzir o mesmo caractere armazenado. A comparação, em vez de rejeitar a tentativa, poderia indicar correspondência. Assim, uma medida contra a enumeração de usuários acabou interagindo com o comportamento da musl de maneira perigosa.

Mudanças posteriores no Alpine ajudam a explicar por que o asterisco continuou presente. Em 2019, após a descoberta de imagens Docker sem senha de root — problema registrado como CVE-2019-5021 — a distribuição bloqueou a conta com “!”. Mas, em sistemas sem PAM, esse marcador também podia impedir autenticação por chave SSH. Em 2022, o Alpine 3.16 adotou “*” para manter a conta bloqueada e permitir o uso de chaves.

A falha não era necessariamente reproduzida em todas as instalações. Sistemas sem senha configurada não eram afetados da mesma forma; era preciso haver uma conta com “*” e uma tentativa de autenticação. Além disso, muitas distribuições usam PAM, que pode não chamar crypt() nesse cenário. Os testes do OpenSSH citados no relato cobriam OpenBSD e glibc, mas não a combinação com musl.

Houve sinais anteriores de que o caractere podia gerar problemas em outros contextos. Uma discussão de 2013 no Debian propôs copiar o comportamento da musl; anos depois, a distribuição migrou para libxcrypt, que usa “*0”. Em dezembro de 2024, uma conversa sobre o BusyBox tratou de falhas com senhas de 257 caracteres, também relacionadas ao limite e ao asterisco. Nenhuma dessas discussões, segundo o relato, apontou para o OpenSSH.

A revisão publicada em outubro de 2026 corrigiu a seleção de salt no OpenSSH. O episódio mostra como uma escolha aparentemente inofensiva em uma biblioteca pode se combinar com decisões de compatibilidade e segurança feitas em projetos distintos. Também evidencia uma lacuna de testes: a interação entre OpenSSH, musl e contas bloqueadas não havia sido coberta — ao menos, não há registro de que tenha sido.