Fragnesia: terceira falha crítica de escalonamento de privilégios no kernel Linux em semanas
Nas últimas semanas surgiu a vulnerabilidade Fragnesia, uma exploração local de escalonamento de privilégios que permite a um usuário sem privilégios obter acesso root com um único comando em sistemas vulneráveis. A prova de conceito pública já está circulando, o que aumenta a urgência das atualizações e das medidas temporárias. Administradores estão enfrentando uma enxurrada de patches, reinicializações e verificações de integridade em servidores de produção. Este texto explica o que é Fragnesia, como o ataque funciona, quais distribuições estão afetadas e quais mitigações e verificações aplicar.
O que é Fragnesia e por que ela se relaciona a Copy Fail e Dirty Frag?
Fragnesia é uma vulnerabilidade de escalonamento de privilégios local rastreada como CVE-2026-46300 com pontuação CVSS de 7,8. Ela pertence à mesma família funcional que Copy Fail e Dirty Frag, pois explora falhas na manipulação de dados e no cache de páginas do kernel para obter uma primitiva de escrita. A descoberta foi atribuída a William Bowling, da equipe V12, e debates técnicos posteriores mostraram que se trata de um bug distinto, não apenas uma reanálise das falhas anteriores. Na prática, as três falhas permitem corromper páginas de cache de arquivos críticos e transformar essas corrupções em execução com privilégios elevados.
Detalhes técnicos: o subsistema XFRM ESP-in-TCP e a lógica da vulnerabilidade
O bug reside no subsistema XFRM, especificamente na implementação ESP-in-TCP (espintcp), usada para processar tráfego IPsec encapsulado em TCP. Quando um socket TCP muda para o modo ESP-in-TCP após páginas de arquivo terem sido enfileiradas por chamadas como splice ou sendfile, o kernel pode interpretar essas páginas como dados ESP e aplicar a operação de ‘descriptografia’ sobre elas. Esse comportamento provoca a injeção de dados relacionados ao fluxo de chaves AES-GCM nas páginas em cache correspondentes a arquivos somente leitura. Controlando parâmetros como o IV e outros valores do fluxo, um atacante não privilegiado consegue direcionar gravações determinísticas em páginas de arquivos lidos, abrindo uma primitiva de escrita arbitrária.
Impacto prático: modificação de binários em cache
A prova de conceito demonstra a modificação da cópia em memória de binários privilegiados, tipicamente o executável /usr/bin/su, através da injeção de um stub ELF na versão em cache. Depois disso, na próxima execução do binário afetado, o stub é executado com privilégios de root, resultando em escalada instantânea. Outro alvo possível são outros binários setuid ou componentes privilegiados carregados em memória, o que amplia o risco em sistemas que expõem muitos binários com privilégios. Essa técnica dispensa truques condicionais complexos e depende apenas do controle fino das gravações no cache de páginas.
Mitigações temporárias quando reiniciar não é uma opção
Embora a correção definitiva exija instalar um kernel corrigido e reiniciar o sistema, existem paliativos adotáveis em produção que não exigem reboot imediato. A abordagem recomendada é bloquear o carregamento dos módulos vulneráveis (esp4, esp6 e, quando aplicável, rxrpc) via regras em /etc/modprobe.d/ e, se já carregados, descarregá-los com rmmod. Essa mitigação impede que a superfície ESP-in-TCP seja usada para explorar a falha, mas também interrompe túneis IPsec que dependam desses módulos no kernel. Em hosts que terminam tráfego IPsec crítico, a aplicação dessa medida deve ser avaliada com cautela por causa do impacto operacional.
Limpar o cache de páginas após aplicar a mitigação
Após negar o carregamento dos módulos vulneráveis, recomenda-se forçar a recarga das páginas em memória para eliminar possíveis cópias corrompidas de binários privilegiados. Isso é conseguido escrevendo um valor em /proc/sys/vm/drop_caches para liberar páginas limpas e dentries/inodes, o que resulta na leitura novamente dos binários do disco quando necessários. A operação é considerada segura em produção, pois não apaga dados sujos, mas pode causar aumento temporário de E/S e impacto de desempenho enquanto o cache é repovoado. Em conjunto com a lista negra de módulos, essa etapa reduz o risco de uma modificação residual no cache ser explorável.
Status dos patches e recomendações dos fornecedores
Várias distribuições já publicaram kernels corrigidos ou estão finalizando pacotes de correção; entre elas estão projetos como AlmaLinux e CloudLinux. Fornecedores maiores estão avaliando se as mitigação aplicadas para vulnerabilidades anteriores cobrem a nova CVE, e notas técnicas apontam que políticas de confinamento como AppArmor e restrições de namespaces podem dificultar a exploração em alguns cenários. Relatos de empresas de segurança ressaltam que a vulnerabilidade permite modificar conteúdo somente leitura no cache de páginas e escalar para root por corrupção determinística de memória. Até o momento da divulgação pública, nenhum atacante ativo foi confirmado, mas a recomendação é aplicar correções assim que disponíveis e, quando impossível, adotar as mitigações descritas.
Contexto da ameaça e impacto operacional
O aparecimento de Fragnesia ocorre num momento em que explorações de LPE para Linux têm alto valor comercial, alimentando um mercado de zero-days. Há relatos de um vazador que estaria oferecendo uma LPE funcional por R$ 901.000,00 com características TOCTOU e payload via biblioteca compartilhada em /tmp. A sucessão de falhas Copy Fail, Dirty Frag e Fragnesia tem gerado fadiga entre administradores, que precisam conciliar disponibilidade e segurança. Soluções de atualização em tempo real, como mecanismos de live-patching, tornaram-se alternativas atraentes para reduzir interrupções ao aplicar correções críticas. Manter-se atento a avisos de segurança, listas de discussão e canais como Mattermost ou X ajuda a reagir com mais rapidez.
Recomendações práticas imediatas
Priorize a aplicação do kernel corrigido e planeje reinicializações controladas nos próximos janelas de manutenção. Se não for possível reiniciar imediatamente, aplique a regra de bloqueio de módulos (esp4, esp6, rxrpc), descarregue-os quando possível e limpe o cache de páginas para eliminar cópias potencialmente corrompidas. Reforce o monitoramento de atividades de escalonamento de privilégios e verifique integridade de binários críticos antes e depois das mitigações. Por fim, avalie soluções de live-patching e revise a política de controle de acesso local para reduzir a superfície disponível a invasores que já possuam conta de usuário.
Sou um profissional na área de Tecnologia da informação, especializado em monitoramento de ambientes, Sysadmin e na cultura DevOps. Possuo certificações de Segurança, AWS e Zabbix.
