ssh-keysign-pwn: Nova falha no kernel do Linux permite acesso root local

Os patches do php2shell (CVE-2026-109618 e CVE-2026-109619) para o PHP em fim de vida (EOL) já estão disponíveis. Como as respostas do atendimento de vendas estão mais demoradas do que o normal devido à alta demanda, a maneira mais rápida de obter os pacotes corrigidos é adquirir o ELS para Runtimes on-line (abre em uma nova aba). Leia as perguntas frequentes sobre os patches

Vá direto para um resumo gerado por IA desta postagem do blog

  • Resuma esta postagem com o Perplexity
  • Resuma esta postagem com o Gemini

Não quer passar por uma quarta janela de reinicialização de emergência neste mês? O KernelCare aplica patches no kernel do Linux sem a necessidade de reinicialização, sem tempo de inatividade nem interrupções.

*Atualização (18/05/2026, 13h UTC): A KernelCare lançou patches que não exigem reinicialização para o Ubuntu 22.04 (Jammy), o Debian 11 (no ePortal), a família EL9 (nos canais test + main) e o RHEL 8/Rocky Linux 8 (no canal test)

A versão resumida

O que: Uma vulnerabilidade de escalonamento de privilégios local no Linux em __ptrace_may_access(), informalmente chamado de ssh-keysign-pwn (ou chage_pwn, em referência ao PoC do título). Nenhum CVE havia sido atribuído até o momento da publicação.

Impacto: A prova de conceito pública consegue, de forma confiável, elevar um usuário local sem privilégios ao nível de root, aproveitando a vulnerabilidade dos binários SUID por meio dessa brecha: chage vazar /etc/shadow, ssh-keysign vazar chaves privadas de hosts SSH.

Status: O correção na origem (confirmar 31e62c2) foi lançado na mesma janela que o divulgação pública na lista de discussão oss-security. Ainda não foi atribuído nenhum CVE, o comunicado da Qualys ainda não foi publicado e ainda não há pontuação CVSS. A KernelCare disponibilizou patches que não exigem reinicialização para o Ubuntu 22.04 (Jammy), o Debian 11 (no ePortal) e a família EL9 (nos repositórios test e main), RHEL 8/Rocky Linux 8 (no canal de testes).

Gravidade: Vetor local, sem necessidade de privilégios, sem interação do usuário, sem configuração especial. O PoC público funciona imediatamente no Debian 11/12/13, Ubuntu 22.04/24.04/26.04, Arch, Raspberry Pi OS Bookworm e nas famílias EL9 e EL10. O EL8 e o Ubuntu 20.04 estão vulneráveis, mas requerem um PoC adaptado. O EL7 com o kernel 3.10 não é afetado.

Por que isso é importante: como a vulnerabilidade tem como alvo binários SUID comuns e não requer privilégios nem interação do usuário, os sistemas Linux multiusuário vulneráveis devem ser considerados em risco imediato.

Faça isso agora: Apertar o Yama ptrace_scope nos servidores (um sysctl, reversível). KernelCare Os clientes devem ficar atentos ao lançamento do feed de testes. Os comandos de mitigação e as instruções para a aplicação de patches sem reinicialização estão abaixo.

A versão completa

Uma vulnerabilidade de acesso root no kernel do Linux foi divulgada no GitHub nesta manhã, sem um ID CVE associado, sem nenhum comunicado do pesquisador que descobriu a falha e com uma demonstração de conceito (PoC) pública que funciona em um sistema Debian ou Ubuntu padrão. O bug está em __ptrace_may_access(). A correção foi incorporada ao código-fonte original nesse mesmo período – uma boa notícia, exceto que ninguém fora das equipes do kernel das distribuições terá acesso a ela por alguns dias.

Aqui estão os detalhes mais precisos da linha do tempo. Jann Horn propôs uma correção equivalente para esse bug em 2020. Ela não foi incorporada. A causa raiz permaneceu em todos os ramos estáveis do kernel por cinco anos, até que um pesquisador da Qualys a redescobriu e um segundo pesquisador publicou dois exploits funcionais no repositório ssh-keysign-pwn poucas horas após a divulgação pelo upstream.

O patch do KernelCare que não requer reinicialização está em fase de compilação. Até que ele seja lançado, há um comando sysctl que bloqueia completamente o PoC público. Veja a seguir o que está acontecendo e o que fazer hoje.

Como funciona a vulnerabilidade

Uma refatoração de 2017 de __ptrace_may_access() (confirmar bfedb589, v4.10-rc1) inverteu silenciosamente a verificação de acesso quando uma tarefa mm é NULL. O código anterior à refatoração negava o acesso nesse estado. O código refatorado permite o acesso.

Durante a saída do processo, há um intervalo da ordem de microssegundos em que task->mm já foi liberada, mas os descritores de arquivo da tarefa ainda estão ativos. O PoC público executa um processo SUID nessa janela usando pidfd_open e pidfd_getfd, com dois alvos já definidos no repositório: chage vazar /etc/shadow, e ssh-keysign para vazar chaves privadas de hosts SSH. A taxa de acerto relatada é de 100 a 2.000 instâncias geradas por tentativa bem-sucedida.

Jann Horn propôs uma correção equivalente em 2020 (v1, v2). Ela não foi incorporada, e o bug permaneceu latente.

Quem é afetado

A regressão foi incorporada retroativamente à série estável v4.4.40; portanto, praticamente todos os kernels de distribuições modernas que não sejam EL7 estão abrangidos por padrão. Três grupos:

A demonstração de conceito (PoC) pública funciona imediatamente:

  • Debian 11, 12, 13
  • Ubuntu 22.04, 24.04, 26.04
  • Arch Linux (atual)
  • Raspberry Pi OS Bookworm
  • CentOS Stream 9, AlmaLinux 9, RHEL 9, Oracle Linux 9, Rocky Linux 9
  • AlmaLinux 10, RHEL 10

Vulnerável, mas a demonstração de conceito (PoC) precisa de adaptação:

  • Família EL8 (RHEL 8, AlmaLinux 8, Rocky 8, Oracle Linux 8)
  • Ubuntu 20.04

Não afetados:

  • Família EL7 no kernel 3.10 – anterior à regressão de 2017

Aja agora para mitigar

Apertar o Yama ptrace_scope. A exploração acessa a falha por meio de pidfd_getfd(). pidfd_getfd() chamadas ptrace_may_access(…, PTRACE_MODE_ATTACH_REALCREDS), que executa o gancho LSM no final de __ptrace_may_access. Uma negação do Yama contorna o bug, independentemente da passagem pela instrução mm-NULL com erro.

O comum ptrace_scope=1 A configuração padrão (do Debian/Ubuntu, tal como vem de fábrica) NÃO é suficiente. Sob scope=1, a ligação de processo pai a filho é permitida. O invasor gera ele mesmo o processo SUID, portanto, ele são o pai ou a mãe. Você deve se mudar para scope=2 ou scope=3.

Recomendado: ptrace_scope=2 (anexo exclusivo para administradores, totalmente reversível em tempo de execução):

sudo sysctl -w kernel.yama.ptrace_scope=2

Reverta após a instalação do patch que dispensa a reinicialização:

sudo rm /etc/sysctl.d/99-ssh-keysign-pwn.conf

Mais forte: ptrace_scope=3 (sem anexo para ninguém, irreversível sem reinicialização):

sudo sysctl -w kernel.yama.ptrace_scope=3

scope=3 é uma ação irreversível até a reinicialização: o kernel rejeita tentativas posteriores de reduzi-lo (sysctl -w kernel.yama.ptrace_scope=2 retornos EINVAL). Escolha essa opção somente se você estiver disposto a reiniciar o sistema para reverter a ação e se o `root debug-attach` (gdb -p, strace -p (como root) não faz parte de suas operações normais.

Compatibilidade

  • scope=2 interrompe os usuários sem privilégios gdb -p / strace -p / perf trace --pid e fluxos de depuração de contêineres O root mantém a conexão, portanto, o diagnóstico de problemas pelo administrador ainda funciona.
  • scope=3 impede o funcionamento do `debug-attach` para todos, inclusive o usuário root.

Patch KernelCare sem reinicialização

A KernelCare lançou patches que não exigem reinicialização para o Ubuntu 22.04 (Jammy), o Debian 11 (no ePortal), a família EL9 (nos repositórios test e main) e o RHEL 8/Rocky Linux 8 (no repositório test)

Assim que for publicado no feed de teste:

kcarectl --update --prefix test

Após a validação, o patch é incluído na próxima execução programada ou pode ser baixado sob demanda:

kcarectl --update

O que observar à medida que a situação se desenrola

  • Atribuição de CVE: (nenhuma até o momento da redação deste artigo)
  • O próprio comunicado da Qualys, que provavelmente conterá uma descrição técnica mais completa
  • Atualizações do kernel de distribuição do Debian, do Ubuntu e dos fornecedores do EL9/10
  • Novas alterações no repositório público ssh-keysign-pwn – é improvável que os dois alvos atuais sejam os únicos viáveis

Atualizaremos esta publicação assim que o CVE for divulgado e quando o patch do KernelCare passar da versão de teste para a estável. Se você estiver usando o KernelCare, o patch será instalado automaticamente, portanto, não é necessário fazer nada.

Se você ainda não é usuário do KernelCare, este é um bom momento para descobrir como a aplicação de patches sem reinicialização pode proteger sistemas Linux críticos sem a necessidade de janelas de manutenção de emergência ou tempo de inatividade.

Saiba mais sobre o KernelCare aqui →

Junte-se a mais de 4.500 profissionais de Linux e código aberto!

2 vezes por mês. Sem spam.

Índice
Obtenha as respostas sobre segurança de código aberto de que você precisa

Junte-se a mais de 4.500 profissionais de Linux e código aberto!

2 vezes por mês. Sem spam.