ssh-keysign-pwn - PoC de 0-day no Linux permite que usuário sem privilégios leia arquivos pertencentes ao root

• ssh-keysign-pwn é uma PoC de vulnerabilidade no Linux que permite a um usuário sem privilégios ler arquivos pertencentes ao root, e afirma que afeta kernels anteriores a 31e62c2ebbfd
• O bug central é estrutural: __ptrace_may_access() pula a verificação de dumpable quando task->mm == NULL, e do_exit() executa exit_mm() antes de exit_files(), criando uma janela em que os descritores de arquivo permanecem abertos
• Nessa janela, se o uid do chamador corresponder ao do processo-alvo, pidfd_getfd(2) tem sucesso, permitindo obter descritores de arquivo abertos de um processo em encerramento
• sshkeysign_pwn obtém /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key e explora o fluxo em que ssh-keysign.c abre chaves com permissão 0600 e sai com EnableSSHKeysign=no antes de permanently_set_uid(), deixando o fd aberto
• chage_pwn obtém /etc/shadow e mira a corrida de encerramento no fluxo em que chage -l <user> faz spw_open(O_RDONLY) e depois remove totalmente os privilégios com setreuid(ruid, ruid)
• A execução é feita com make e depois ./sshkeysign_pwn para as chaves do host, ou ./chage_pwn root para imprimir o conteúdo de /etc/shadow na saída padrão; o texto afirma que o acerto ocorre dentro de 100 a 2000 spawns
• Os ambientes confirmados são Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch e CentOS 9
• Como PoC de alvo controlado, vuln_target.c abre /etc/shadow e depois reduz privilégios, enquanto exploit_vuln_target.c mostra EPERM enquanto o processo está vivo e o roubo de fd após SIGKILL
• A vulnerabilidade foi reportada pela Qualys, Linus a corrigiu em 2026-05-14, e Jann Horn teria apontado uma forma de roubo de FD em outubro de 2020
• O README aponta a entrada no NVD em https://nvd.nist.gov/vuln/detail/CVE-2026-46333

[GN⁺]

Comentários do Lobste.rs

• Desativar o ptrace por si só não é suficiente. É fácil se confundir por causa da mensagem de commit e do nome da função, mas ptrace_may_access é chamado por vários caminhos, e esta prova de conceito (PoC) na prática nem usa ptrace
  Não há uma mitigação muito adequada e, por enquanto, parece que as opções são 1) remover o bit de execução de /usr/lib64/misc/ssh-keysign por completo só para responder de forma limitada a esta PoC específica, ou 2) bloquear pidfd_getfd com algo como eBPF ou systemtap. A primeira opção é o tipo de coisa a considerar quando você não pode aplicar um patch no kernel nem desligar a máquina e precisa ir dormir agora mesmo
  Não revisei a PoC e, como sempre, é preciso ter cuidado ao executar qualquer PoC aleatória baixada da internet
  O aviso da Qualys ainda não foi publicado, e eles já disseram que lamentam muito interromper a divulgação para a lista linux-distros por causa da política de segurança do kernel Linux. Com LLMs conseguindo gerar rapidamente uma PoC a partir de commits suspeitos de correção, a situação ficou mais áspera; antigamente talvez fosse possível esperar alguns dias
  A Qualys é realmente uma equipe excelente, então é uma pena que não tenham podido ter um momento adequado para anunciar isso por conta própria. Quando for publicado, imagino que será um ótimo aviso
  O openssh é apenas um alvo conveniente para este ataque e não tem culpa; outros binários setuid também poderiam ser escolhidos como alvo

  • Segundo a atualização da Qualys, definir /proc/sys/kernel/yama/ptrace_scope como 2 (attach apenas para admin) ou 3 (sem attach) bloqueia todos os exploits conhecidos. Ainda assim, em teoria podem existir outras formas de exploração
  • Como mitigação rápida, pedi ao LLM Opus para escrever um script systemtap que bloqueia pidfd_getfd, e o resultado está aqui. É preciso executá-lo com stap -g block_pidfd_getfd.stp e, como qualquer coisa baixada da internet, o script deve ser revisado antes de rodar
  • Existe algum link para o anúncio no linux-distros? Não consigo encontrar

• Eu gostaria que o kernel parasse de fazer sua própria divulgação de 0-day ao publicar commits de correção no branch principal. O commit até diz “Reported-by: Qualys”, então está claro que é uma correção de segurança

  • Houve uma grande discussão sobre isso na semana passada
    Greg K-H escreveu que, como a equipe de segurança do kernel não pode escolher quem recebe pré-divulgação de correções de segurança, no fim ninguém recebe pré-divulgação
  • Então o que deveria ser feito no lugar?

• Isto não é um problema do ssh, e sim um problema do Linux. O título deveria refletir isso

  • Concordo que o título induz ao erro, mas não tive outra ideia de como chamá-lo. Ainda dá para editar, então sugestões seriam bem-vindas
  • Sim, mas ao mesmo tempo, se o ssh-keysign verificasse EnableSSHKeysign=yes antes de abrir a chave privada do host, então sistemas em que essa opção está desativada, como no padrão, não seriam vulneráveis ao roubo da chave do host. É surpreendente que o ssh-keysign não verifique essa opção antes de mais nada

• A prova de conceito é agradavelmente curta, e minhas máquinas também eram realmente vulneráveis
  Pelo que parece, isso permite acessar descritores de arquivo abertos por executáveis setuid sob certas condições. Não vejo por que isso teria de se limitar a leitura, e parece que poderia ser transformado em uma elevação local de privilégio (LPE) sem precisar quebrar hashes
  Esta PoC específica pode ser neutralizada com chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage. Talvez seja necessário ajustar o caminho de ssh-keysign, e a página de manual também pode ajudar. Mas isso não corrige o problema central e parece possível contornar. Até onde eu saiba, não há outras mitigaçãoes
  Este problema foi corrigido em ptrace: slightly saner 'get_dumpable()' logic, e foi assim que acabou sendo exposto. Isso foi há apenas 10 horas
  Também há um anúncio público da Qualys enviado ao oss-security, dizendo que ainda não publicariam o aviso para dar tempo de distribuições e usuários aplicarem patches. Parece que será uma leitura bem interessante; por enquanto, vale ver a explicação de Brad Spengler, da grsecurity. Esse tweet parece ter sido o gatilho para o desenvolvimento desta PoC

  • Tentei executar a PoC, mas não consegui vencer a race condition. Em compensação, o par exploit_vuln_target/vuln_target funcionou bem. Nada bom

• Na prática, isso parece afetar sistemas que já têm um usuário com conta sem privilégios. Ou seja, se não houver um login válido, está certo dizer que não dá para conseguir execução remota de código diretamente com isso em um servidor SSH exposto à internet?

  • Sim. A exceção seria se você pudesse obter RCE por meio de outro serviço, como a execução remota de código no nginx que apareceu alguns dias atrás