O seu servidor Alpine aceita qualquer palavra-passe? Basta ter mais de 256 caracteres

Uma falha com uma década permite entrar por SSH em contas que, em teoria, nunca deveriam aceitar uma palavra-passe. Para isso, basta escrever uma palavra-passe muito longa. O problema afeta servidores OpenSSH em sistemas Linux baseados na biblioteca musl libc, como o Alpine Linux, quando a autenticação não passa pelo PAM. O OpenSSH 10.6p2 foi lançado com uma solução de contorno para uma vulnerabilidade crítica e o Alpine Linux publicou pacotes corrigidos no mesmo dia, 5 de novembro de 2026.

Um asterisco com dois significados

A vulnerabilidade foi descoberta por Özgün Kültekin, da empresa Wakefield, que lhe deu o nome *sshole. O problema nasce do encontro entre duas convenções antigas. No mundo Unix, um asterisco no campo da palavra-passe significa que a conta não tem nenhuma palavra-passe utilizável. É o caso das contas de serviço, das contas que só aceitam chaves SSH e, em muitas imagens, da própria conta root.

O segundo ingrediente é o comportamento da função crypt() do musl. As implementações SHA-256 ($5$) e SHA-512 ($6$) de crypt() no musl aceitam no máximo 256 bytes. Com palavras-passe mais longas, a função devolve um asterisco literal em vez de NULL. A escolha remonta a 2012. Em agosto desse ano, o musl passou a devolver * em vez de NULL em caso de erro (a norma POSIX prevê NULL) e, a 29 de agosto, introduziu o limite de 256 bytes. Segundo a explicação de Kültekin, o limite servia para evitar abusos: o hashing SHA-512 fica mais lento quanto maior for a palavra-passe, e entradas gigantes podiam servir para ataques de negação de serviço.

Sem PAM, o OpenSSH calcula o hash da palavra-passe recebida com crypt() e compara-o diretamente com o valor guardado. Com uma palavra-passe de 300 caracteres, crypt() falha e devolve *. Se a conta também tiver * no /etc/shadow, as duas cadeias são iguais e o acesso é concedido. Há ainda um mecanismo do próprio OpenSSH envolvido. Nas contas sem palavra-passe definida, o OpenSSH usa o salt $5$ ou $6$ de outra conta do sistema, para impedir a enumeração de utilizadores por medição de tempos (CVE-2016-6210). É por isso que a falha data de 2016, e que o ataque exige uma conta marcada com asterisco e outra com um hash de palavra-passe válido.

Quem está exposto

O ataque só funciona se todas as condições abaixo se verificarem ao mesmo tempo:

• sshd ligado à musl libc. Isto inclui distribuições como Alpine Linux, OpenWrt, Buildroot e Yocto, além de muitas imagens de contentores;
• OpenSSH sem PAM. É o caso do pacote openssh-server do Alpine, compilado sem PAM, ou do openssh-server-pam com UsePAM no. Com UsePAM yes, o openssh-server-pam não é afetado.
• PasswordAuthentication ativo, que é a predefinição do OpenSSH se não tiver sido alterada;
• Pelo menos uma conta com exatamente * no campo da palavra-passe. As contas bloqueadas com ! não são afetadas.

Segundo o OpenSSH, a vulnerabilidade não existe em sistemas que não sejam Linux, em sistemas Linux com glibc nem em sistemas Linux que usam PAM para autenticar palavras-passe. O Dropbear também não é afetado, o que é relevante porque este servidor SSH é muito usado em equipamentos embebidos com musl.

Dá mesmo acesso de root?

Depende da configuração. No aviso de segurança do Alpine Linux, a conta root aparece entre as afetadas, porque é distribuída como root:* na imagem base desde aproximadamente o Alpine 3.16. O mesmo aviso explica, porém, que a predefinição PermitRootLogin prohibit-password do OpenSSH protege o root, que só fica acessível se estiver definido PermitRootLogin yes.

O caminho mais preocupante passa pelas imagens de cloud. Segundo Kültekin, as imagens oficiais do Alpine para AWS e Azure trazem por predefinição uma conta ‘alpine’ afetada, com privilégios ‘doas’ sem palavra-passe, o que pode dar acesso de root a um atacante. Já existe código de prova de conceito público no GitHub, o que torna a atualização mais urgente.

Identificador CVE e gravidade

À data de publicação, o identificador ainda não aparecia de forma consistente nas várias fontes. Empresas de segurança como a IONIX referem o CVE-2026-123158 e indicam que o registo CVE lhe atribui CVSS 3.1 de 8,1 (elevado), estando a análise do NVD pendente. Nem o OpenSSH nem o Alpine destacam este número nas comunicações consultadas. Recomenda-se, por isso, que as equipas confirmem o identificador no NVD antes de o usarem em relatórios internos. O OpenSSH classifica a vulnerabilidade como crítica.

Cronologia

A rapidez da resposta tem uma explicação. Na mensagem enviada à lista de desenvolvimento, Damien Miller, do OpenSSH, diz que a equipa publicou a versão o mais depressa possível (soube do problema na véspera) porque observou recentemente vários casos de redescoberta rápida de falhas por agentes de IA, por vezes em poucas horas. A mesma mensagem refere que o OpenSSH considera que a causa principal do problema está fora do OpenSSH. Do lado do musl, a conta do responsável pela manutenção no Mastodon contestou que se trate de uma vulnerabilidade da biblioteca.

Versões corrigidas do Alpine

O Alpine 3.21 deixou de ter suporte a 1 de novembro de 2026, mas a distribuição publicou pacotes corrigidos para todas as versões até à 3.16. Segundo a lista compilada pela IONIX a partir do aviso do Alpine, estas são as versões mínimas do pacote openssh:

O que fazer agora

• Confirmar a exposição: verifique se o sshd está ligado ao musl (por exemplo, procurando ld-musl na saída de ldd /usr/sbin/sshd). Com sshd -T, veja os valores de usepam, passwordauthentication e permitrootlogin, e procure contas com * no /etc/shadow.
• Atualizar e reiniciar: no Alpine, execute apk upgrade -U -a e depois rc-service sshd restart. Atualizar o pacote, por si só, não substitui o daemon que está em execução.
• Mitigação imediata: se ainda não puder atualizar, desative pelo menos o login por palavra-passe, definindo PasswordAuthentication no na configuração do sshd e reiniciando o serviço. Nos ramos anteriores ao 3.16, que não têm pacote corrigido, esta é a única proteção disponível.
• Contentores e imagens: reconstrua e volte a implementar as imagens que instalam openssh-server. Uma imagem antiga volta a introduzir a falha sempre que é lançada.
• Procurar sinais de abuso: nos registos de autenticação, procure logins por palavra-passe bem-sucedidos (Accepted password) em contas que só deviam aceitar chaves, como root, alpine ou contas de deploy.

Porque é que isto importa em Portugal

O Alpine é uma das imagens base mais usadas em contentores Docker, e o OpenWrt e o Buildroot estão presentes em routers e outros equipamentos embebidos. Muitas PME e equipas de desenvolvimento em Portugal usam estes sistemas sem saberem que têm um servidor SSH com autenticação por palavra-passe ativa. O caso mostra também que as definições predefinidas podem enganar: uma conta “sem palavra-passe” não é necessariamente uma conta fechada.

As entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2) têm de gerir vulnerabilidades e aplicar correções em prazos adequados. Se um acesso indevido se transformar num incidente significativo, têm de o notificar ao CNCS/CERT.PT. Se o servidor comprometido tiver dados pessoais, o RGPD pode obrigar a notificar a CNPD no prazo de 72 horas. Neste caso, a correção é simples e já está disponível, o que torna difícil justificar adiá-la.

Perguntas frequentes

O meu servidor Ubuntu ou Debian está afetado?

Não. A falha só afeta sistemas Linux com musl libc em que o OpenSSH não usa PAM. As distribuições baseadas em glibc, como Debian, Ubuntu, Fedora ou RHEL, não são afetadas.

Que comprimento de palavra-passe é preciso para explorar a falha?

Os relatos indicam palavras-passe entre 257 e 1024 bytes. Acima de 256 bytes, a função crypt() do musl falha e devolve um asterisco, que coincide com o asterisco guardado nas contas sem palavra-passe.

Basta atualizar o pacote openssh?

Não. Depois de atualizar, é preciso reiniciar o sshd, porque o processo que está a correr continua vulnerável. As imagens de contentores também têm de ser reconstruídas e voltar a ser implementadas.

E se não puder atualizar já?

Desative a autenticação por palavra-passe definindo PasswordAuthentication no na configuração do sshd e reinicie o serviço. Também pode desligar o SSH nos sistemas afetados até aplicar a correção.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pelo Alpine Linux, pelo projeto OpenSSH, pelo OpenBSD Journal, pela IONIX e pelo BleepingComputer.