Dirty Frag: vulnerabilidade LPE local genérica no Linux

 (openwall.com)
2 pontos por GN⁺ 2 시간 전 | 2 comentários | Compartilhar no WhatsApp
  • Dirty Frag é uma vulnerabilidade local genérica de escalonamento de privilégios que permite obter privilégios de root em praticamente todas as principais distribuições Linux; como o cronograma de divulgação responsável e o embargo foram quebrados, ainda não há patch nem CVE
  • Como uma extensão da mesma classe de bugs de Dirty Pipe e Copy Fail, trata-se de um bug lógico determinístico, portanto não requer condição de corrida e tem taxa de sucesso muito alta
  • A vida útil efetiva da vulnerabilidade é de cerca de 9 anos, e ela já foi testada em distribuições principais como Ubuntu, RHEL, Fedora e openSUSE
  • Mesmo sistemas que aplicaram a mitigação existente para o Copy Fail (blacklist de algif_aead) continuam vulneráveis ao Dirty Frag
  • Como mitigação temporária, recomenda-se remover os módulos esp4, esp6 e rxrpc até que as distribuições publiquem patches

Visão geral

  • Trata-se de uma classe de bugs que corrompe o membro frag da estrutura sk_buff, uma extensão da mesma classe de bugs à qual pertencem Dirty Pipe e Copy Fail
  • É possível encadear as vulnerabilidades xfrm-ESP Page-Cache Write e RxRPC Page-Cache Write para obter privilégios de root nas principais distribuições Linux
  • Por ser um bug lógico determinístico, não depende de janela de timing, e não requer condição de corrida
  • Mesmo quando o exploit falha, não ocorre kernel panic, e a taxa de sucesso é muito alta

Motivo para encadear as duas vulnerabilidades

  • xfrm-ESP Page-Cache Write fornece uma poderosa primitiva STORE arbitrária de 4 bytes, semelhante ao Copy Fail, e está presente na maioria das distribuições, mas exige permissão para criar namespaces
  • No Ubuntu, a política do AppArmor pode bloquear a criação de user namespaces sem privilégios, e nesse ambiente não é possível acionar o xfrm-ESP Page-Cache Write
  • RxRPC Page-Cache Write não exige permissão para criar namespaces, mas o próprio módulo rxrpc.ko não está incluído na maioria das distribuições
    • Ainda assim, no Ubuntu o módulo rxrpc.ko é carregado por padrão
  • Ao encadear as duas vulnerabilidades, seus pontos fracos se complementam, tornando possível obter privilégios de root em todas as principais distribuições

Relação com o Copy Fail

  • O Copy Fail foi a motivação para o início desta pesquisa
  • xfrm-ESP Page-Cache Write compartilha o mesmo sink do Copy Fail, mas pode ser acionado independentemente da disponibilidade do módulo algif_aead
  • Mesmo sistemas que aplicaram a mitigação publicada para o Copy Fail (blacklist de algif_aead) continuam vulneráveis ao Dirty Frag

Escopo do impacto

  • xfrm-ESP Page-Cache Write: do commit cac2661c53f3 (2017-01-17) até o upstream atual
  • RxRPC Page-Cache Write: do commit 2dc334f1a63a (2023-06) até o upstream atual
  • A vida útil efetiva da vulnerabilidade é de cerca de 9 anos
  • Versões de distribuições testadas:
    • Ubuntu 24.04.4: 6.17.0-23-generic
    • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed: 7.0.2-1-default
    • CentOS Stream 10: 6.12.0-224.el10.x86_64
    • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44: 6.19.14-300.fc44.x86_64

Medidas de mitigação

  • Como o cronograma de divulgação responsável e o embargo foram quebrados, não existe patch para nenhuma distribuição neste momento
  • Como mitigação temporária, é fornecido o comando para remover os módulos nos quais a vulnerabilidade ocorre: 
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    • Registra os módulos esp4, esp6 e rxrpc em /etc/modprobe.d/dirtyfrag.conf como blacklist e os descarrega
  • Depois que cada distribuição fizer o backport dos patches, será necessário aplicar essas atualizações

Histórico da divulgação

  • O documento do Dirty Frag foi publicado após coordenação com os mantenedores de linux-distros@vs.openwall.org, a pedido deles
  • O embargo foi quebrado por fatores externos, e no momento não existem patch ou CVE
  • O PoC foi divulgado após coordenação com linux-distros com o objetivo de fornecer informações precisas, e seu uso em sistemas não autorizados é proibido

Leituras relacionadas

2 comentários

 
GN⁺ 1 시간 전
Comentários do Hacker News

  • Isso é muito parecido com o Copy Fail tanto na causa raiz quanto na forma de exploração
    Acho que é um bom exemplo do que se perde facilmente ao delegar muito trabalho a LLMs, ou seja, exploração. Quando se faz pesquisa de vulnerabilidades com IA, parece que a criatividade fica bastante bloqueada. Num fluxo em que você faz uma pergunta e recebe a resposta na hora, você deixa de ver o que existe ao redor. É como um gênio: entrega exatamente o que você pediu, e nada além disso
    O pesquisador que encontrou o Copy Fail viu algo suspeito e depois dependeu bastante de IA, mas se tivesse vasculhado mais código manualmente, provavelmente teria tido mais chances de encontrar bugs gêmeos como este. Ao mesmo tempo, se tivesse usado prompts um pouco menos diretivos, acho que os LLMs atuais também teriam encontrado esses bugs. É um caso bem peculiar de sinergia negativa: trabalharam juntos e o desempenho piorou

    • Se eu não li errado, não é só parecido, é a mesma causa raiz. São os 32 bits superiores do Extended ESN do IPsec == problema no módulo/modo de cifra authencesn
      No copy.fail consertaram a coisa errada, e as pessoas correram para culpar o AF_ALG
      [edit: sim, é o mesmo problema do authencesn. No código https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... o authencesn só aparece nos comentários, mas ainda assim é o mesmo problema]
      [edit2: o problema de RxRPC é separado; aqui estou falando do lado ESP]
    • Também daria para usar um prompt de continuação como “encontre bugs de tipo parecido”. Depois que um caso concreto é documentado, achar bugs semelhantes não é tão difícil assim
      Entendo o ponto sobre criatividade. Como qualquer ferramenta, a IA pode estreitar seu campo de visão. É difícil usá-la só como apoio sem entregar o fluxo inteiro
    • Não entendo. Afinal, foram LLMs que descobriram esses bugs. Mas você parece estar tratando essa descoberta como um sinal de que LLMs são ruins para encontrar vulnerabilidades
    • Fico curioso se isso tem base ou se foi só uma reflexão improvisada
    • Diante de uma vulnerabilidade raiz parecida com a que a IA achou, mas não exatamente a mesma, é muito difícil tirar como lição que a IA não consegue explorar
      Tirando o caso em que as duas vulnerabilidades fossem divulgadas juntas como uma só, em que cenário contrafactual isso seria considerado “explorou bem o suficiente”?

  • “Como o embargo foi quebrado, não há patch nem CVE para essas vulnerabilidades”
    Link: https://github.com/V4bel/dirtyfrag
    Análise detalhada: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
    A parte importante é esta: “O Copy Fail foi a motivação para começar esta pesquisa. Em particular, a escrita no page cache xfrm-ESP da cadeia de vulnerabilidade Dirty Frag compartilha o mesmo sink do Copy Fail. Porém, ela é acionável independentemente de o módulo algif_aead estar disponível. Em outras palavras, mesmo em sistemas com a mitigação pública do Copy Fail, que é a blacklist do algif_aead, o Linux continua vulnerável ao Dirty Frag”
    A mitigação seria a seguinte, embora eu não tenha testado nem verificado pessoalmente: “Como o cronograma de divulgação responsável e o embargo foram quebrados, não há patches em nenhuma distribuição. Remova os módulos que disparam a vulnerabilidade com o comando abaixo”
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    Na discussão sobre mitigação, disseram que pode ser necessário reiniciar e que, em máquinas já exploradas, depois do comando acima seria preciso executar: sudo echo 3 > /prox/sys/vm/drop_caches

    • Em sudo echo 3 > /prox/sys/vm/drop_caches, o sudo não faz efeito. O sudo executa só o echo, não a escrita de fato
      E, se a máquina já foi explorada, esse ponto já passou faz tempo. Qualquer coisa no disco pode ter sido corrompida, então seria preciso recriar a imagem do disco inteiro
    • Não dá para usar sudo echo com redirecionamento desse jeito em um shell sem sudo
      echo 3 | sudo tee /proc/sys/vm/drop_caches
      ou
      sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
      E também corrigi o erro de digitação em /proc
    • Só para constar, echo 1 > ... também mitiga. Não precisa limpar tudo; basta apagar o page cache com 1
      Testei localmente no Ubuntu 26.04: executei o exploit, obtive root, configurei a mitigação e então rodei su de novo sem argumentos; virei root imediatamente e sem senha. Depois de limpar o page cache, su passou a pedir senha

  • Precisamos de uma forma fácil de garantir que apenas módulos de kernel em whitelist possam ser carregados. Cansei de ficar colocando em blacklist módulos de que ninguém precisa

  • Vou perguntar de novo: por que no copy.fail o algif_aead leva toda a culpa? O estúpido é o authencesn
    O authencesn não foi corrigido, e agora veio o resultado disso. Descobriu-se que o mesmo, provavelmente o mesmo, out-of-bounds write pode ser alcançado por meio de um socket de rede comum
    Eu gostaria de ter pensado nisso, mas não pensei
    [edit: estou falando do problema via ESP. O problema de RxRPC, pelo que entendo, é completamente separado]

  • Se isso realmente funciona em todas as principais distribuições, continuo impressionado com o quanto os mantenedores são irresponsáveis. Por que recursos opcionais do kernel, úteis talvez para menos de 0,1% dos usuários, vêm ativados por padrão?
    Lembra a prática das distribuições Linux de 1999, que instalavam por padrão dezenas de serviços de rede expostos à internet. Só que agora não é 1999

    • É pedir bastante que o mantenedor da distribuição decida colocar algo em blacklist com base em “você não vai precisar disso” (YAGNI). Não tem como saber o que cada pessoa usa. O usuário sempre pode depois ajustar a build ao que realmente quer
      Lembro do começo do Linux, quando a gente rodava make menuconfig para escolher exatamente o que queria no kernel. Sinceramente, não tenho vontade nenhuma de voltar para aquilo
      Dito isso, um alvo fácil de melhoria aqui é o RHEL. O RHEL compila muita coisa direto no kernel em vez de deixar como módulo carregável, o que tornava mitigação como a do copy fail impossível. Talvez desse para reduzir um pouco isso
    • Não existe jeito de desativar componentes que o usuário talvez não use sem tornar o sistema absurdamente difícil de usar. Mesmo eu, depois de 25 anos usando esse SO idiota, não tenho como saber o que preciso ligar ou desligar para fazer alguma coisa
      Os mantenedores de distribuições Linux são os mantenedores de software mais responsáveis do planeta. As práticas de segurança deles são muito melhores do que as de gerenciadores de pacotes idiotas de linguagens de programação; eles mantêm uma lista curada de pacotes, revisam mudanças, corrigem bugs, resolvem problemas complexos de empacotamento, fazem backport de correções, usam lançamentos em fases, distribuem arquivos por espelhos no mundo inteiro e verificam criptograficamente todos os arquivos. E não dá para esquecer que fazem tudo isso de graça
    • Isso não vem ativado por padrão. São módulos opcionais carregados quando necessário. Toda a arquitetura do kernel é organizada para que o essencial de que o usuário precisa fique compilado, e quase todo o resto seja fornecido como módulo carregado sob demanda
    • Em muitos aspectos, computadores não móveis ainda vivem em 1999. O Android é muito mais novo e teve a chance de integrar controle de acesso obrigatório em toda a stack, então é muito mais seguro que outros sistemas Linux
    • Para explorar isso, você precisa ter acesso direto ao computador. Tem de ser por um dispositivo USB malicioso, ou um ataque à cadeia de suprimentos, ou pela exploração de algum software conhecido que o usuário instale de forma voluntária ou automática. Além disso, na prática, você já precisa conseguir executar comandos arbitrários no terminal, o que por si só já é uma violação enorme do isolamento daquele software
      Se o atacante já conseguiu tudo isso, a situação já está ruim. Escalar para root com isso é uma das menores preocupações nesse ponto
      Como outra pessoa postou abaixo: https://xkcd.com/1200/
      As pessoas precisam entender o que essa vulnerabilidade realmente é antes de entrar em pânico

  • Depois de tantos anos, finalmente chegamos ao estado em que “com olhos suficientes, todo bug é superficial”, e isso é meio ruim. Vamos ter que fazer atualização de kernel várias vezes por semana agora?

    • Você está presumindo que alguém vai invadir sua casa, dar um jeito de achar credenciais padrão e ainda obter acesso root?

  • Fico curioso sobre como o embargo foi quebrado. Foi vazamento ou algum terceiro encontrou de forma independente?

    • Para começo de conversa, embargo não existe e não pode existir
      O Linux é open source, então todo patch que corrige bug de segurança fica imediatamente visível para todo mundo. Pela forma como o desenvolvimento do kernel funciona, não há como contornar isso. O que as pessoas chamam de “embargo” é a ideia meio idiota de que, se você não escrever explicitamente “THIS IS A LPE” na descrição do patch e ficar calado, pode fingir que a vulnerabilidade não vazou até sair a mensagem “oficial” na mailing list
      Talvez essa abordagem fosse defensável antigamente, mas na era dos LLMs ela não é só idiota, é perigosa, porque dá para pegar os diffs da mailing list, jogar num pipeline automático para os modelos mais recentes e pedir que identifiquem se o patch corrige um problema de segurança
    • O link do patch apareceu na conta de alguém no X, e outra pessoa viu aquilo e publicou um exploit funcional menos de uma hora depois. Pode até ter sido com ajuda de LLM, mas fora o tempo de resposta muito curto, isso não passa de especulação
      https://x.com/encrypted_past/status/2052409822998392962
    • Um terceiro sem relação publicou isso publicamente

  • Alguém sabe se o Debian é vulnerável? Tentei o exploit em máquinas com Debian 12 e Debian 13, mas não consegui reproduzir pessoalmente

    • Consegui reproduzir no kernel 6.12.57+deb13-amd64 do Debian 13, ou seja, Trixie, mas não no kernel 6.1.0-42-amd64 do Debian 12 Bookworm
      Para quem usa Bookworm sem a security stream de pacotes do Debian, o kernel 6.1.0-42-amd64 é de fato imune ao copy.fail. É surpreendente que também pareça imune ao dirtyfrag. Se a security stream ainda não corrigiu, talvez dê para escolher uma versão de kernel que mantenha o commit 2b8bbc64b5c2. Acho que esse mesmo commit pode estar tornando por acaso algumas versões do kernel do Debian 12 seguras contra o dirtyfrag também
    • Acabei de testar o exploit num droplet novo de Debian 13 da DigitalOcean e funcionou
    • Testei em um Debian 13 totalmente atualizado e o exploit funciona. Também confirmei que a mitigação funciona

  • Executei isso em um contêiner ubuntu:latest com um novo usuário padrão
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    Resultado: dirtyfrag: failed (rc=3)
    Boa notícia!

    • Quando executei dentro de um contêiner, obtive o mesmo resultado, mas ao executar diretamente no host consegui um shell. Isso só mostra que o exploit não funciona dentro do contêiner. Portanto, ou o contêiner não é vulnerável, ou o script precisa de ajustes para funcionar em contêiner
      O copy fail pode ser usado para escapar de contêineres (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), então imagino que este exploit precise apenas de pequenas mudanças
    • É difícil considerar contêineres uma plataforma confiável para esse tipo de teste. Seja por comportamento esperado ou não, muita coisa falha dentro de contêineres
 
GN⁺ 2 시간 전
Comentários no Lobste.rs

  • Foi realmente uma semana e tanto para administrar servidores Linux compartilhados. Ainda assim, gostei que esta divulgação foi direto ao ponto.
    Só não entendo por que, nas orientações de mitigação, todo mundo esconde o stderr.
    Edit: isso diz que foi reportado em 30 de abril, inspirado pelo copy.fail — então foi descoberto em menos de um dia? Impressionante.
    Como alguém com privilégios de sudo em um servidor compartilhado bem grande, também me pergunto se compilar o kernel manualmente com o menor número possível de módulos incluídos seria uma boa ideia. Não analisei os prós e contras a fundo, mas parece que isso poderia ter evitado as duas vulnerabilidades de escalonamento local de privilégios desta semana.
    Edit 2:

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    Ah, isso não precisa de setuid. Bom que incluíram.

    • Faço isso em um sistema multiusuário que mantenho, e consegui realmente evitar os dois exploits locais de root desta semana.

  • Seria possível e razoável pegar a lista de módulos do kernel carregados em um sistema em execução e defini-la como uma allowlist de modprobe para aquele sistema?
    Tanto o CopyFail quanto o DirtyFrag parecem explorar módulos do kernel que não estavam carregados em nenhum dos sistemas que verifiquei. Nesse caso, bloquear módulos que claramente não parecem necessários talvez pudesse mitigar preventivamente alguns ataques.

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    Não entendo como isso é permitido. Parece simplesmente absurdo que informações desse porte estejam em um ambiente tão difícil de confiar.

    • Não tenho certeza se o “terceiro não relacionado publicou” se refere a este caso, mas, para referência, Brad Spengler viu o commit de correção subir primeiro, percebeu a vulnerabilidade de segurança implícita na mensagem do commit, e em uma resposta alguém criou um exploit com vibe coding.
      Qualquer terceiro observando os commits do Linux poderia ter seguido as mesmas pistas e produzido um exploit.
    • A expressão “terceiro não relacionado” soa como se significasse que essa pessoa não sabia que o bug estava sob embargo.
      O “ambiente difícil de confiar” aqui é a internet inteira, e na prática não existe muito que se possa chamar de isolamento. Sempre foi assim, só que agora isso está ainda mais claro. Também vale ver o post recente de Stefan Eissing sobre um bug do Apache httpd ter sido redescoberto duas vezes antes de a correção ser lançada.

  • Existe alguma forma de testar se os módulos afetados realmente não podem ser carregados?
    No caso do CopyFail, cometi um erro ao aplicar a mitigação inicial. O nome do arquivo em /etc/modprobe.d/ não terminava com .conf, e eu só percebi depois de executar o comando de teste em https://news.ycombinator.com/item?id=47954159. Haveria algum comando semelhante para os módulos esp4/esp6/rxrpc?

    • Tentei carregar os três módulos com modprobe, e deu o mesmo erro da vez passada.
      Também há um código de prova de conceito anexado, mas ainda não tentei usá-lo.