A cadeia combina primitivas de escrita no cache de páginas em xfrm-ESP e RxRPC, afetando distribuições Linux amplamente usadas e podendo levar acesso local sem privilégio a root.
| Componente | Núcleo Linux, com primitivas em xfrm-ESP/IPsec e RxRPC, associadas aos módulos esp4, esp6 e rxrpc. |
| Vetor | Usuário local sem privilégio aciona caminhos de rede e buffers apoiados por cache de páginas, inclusive fluxos relacionados a splice(2), sendfile(2) e MSG_SPLICE_PAGES; uma variante depende de criação de namespace e a outra depende da presença de rxrpc.ko. |
| Impacto | Escalonamento local para root, corrupção de memória apoiada por cache de páginas e risco condicionado de escape de contêiner quando cargas de terceiros executam no mesmo host. |
| Prioridade | Aplicar correções do núcleo assim que disponíveis, validar exposição dos módulos vulneráveis e bloquear o carregamento de esp4, esp6 e rxrpc quando compatível com a operação. |
| Versões | Exploração demonstrada ou indicada contra Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10 e Fedora 44. |
| Artefatos | CVE-2026-43284 para a falha em xfrm-ESP, corrigida no mainline em f4c50a4034e6; CVE-2026-43500 para a falha em RxRPC, corrigida no mainline em aa54b1d27fe0. |
| Atividade observada | Telemetria limitada descreve acesso inicial via SSH, shell interativo, execução de binário ELF ./update, acionamento de escalonamento por su, inspeção de GLPI e interação com arquivos de sessão PHP. |
Dirty Frag é uma cadeia de escalonamento local de privilégios no núcleo Linux que combina duas falhas de escrita sobre memória apoiada pelo cache de páginas. A primeira fica no subsistema xfrm-ESP, usado por IPsec, e a segunda fica em RxRPC. Em vez de depender de uma janela de corrida instável, a cadeia usa condições lógicas determinísticas nos caminhos de recepção e descriptografia do núcleo. Quando o fluxo vulnerável recebe fragmentos paginados que não pertencem de forma exclusiva ao núcleo, a operação pode alterar dados ainda referenciados por um processo local, criando uma primitiva de corrupção útil para elevar privilégios.
A exposição é relevante porque o ataque parte de uma conta local sem privilégio e termina em execução como root em sistemas vulneráveis. Em hosts tradicionais, isso transforma acesso limitado ao sistema operacional em controle administrativo. Em ambientes com contêineres, o risco depende das permissões concedidas à carga de trabalho e dos perfis de isolamento aplicados, mas a falha pode ampliar o impacto quando processos de terceiros conseguem alcançar interfaces vulneráveis do núcleo. A cadeia também contorna uma mitigação aplicada para Copy Fail: bloquear algif_aead não remove a superfície de Dirty Frag, pois a exploração não depende desse módulo.
As duas vulnerabilidades receberam identificadores distintos após a atualização das correções. A falha no caminho xfrm-ESP foi registrada como CVE-2026-43284 e corrigida no ramo principal do núcleo pelo commit f4c50a4034e6. A falha em RxRPC foi registrada como CVE-2026-43500 e corrigida pelo commit aa54b1d27fe0. A prioridade operacional é tratar a cadeia como uma falha de escalonamento local confiável, revisar a presença dos módulos afetados e acelerar a distribuição de pacotes de núcleo corrigidos nos ramos usados em produção.
A variante em xfrm-ESP explora um caminho rápido de descriptografia em ESP sobre UDP associado a páginas passadas por mecanismos como splice(2), sendfile(2) e MSG_SPLICE_PAGES. O problema ocorre quando o núcleo processa um socket buffer contendo fragmentos paginados que não são cópias privadas controladas exclusivamente pelo núcleo. Ao descriptografar ou manipular o conteúdo diretamente sobre essas páginas, o caminho vulnerável pode modificar memória que continua vinculada ao cache de páginas e ainda pode ser observada ou influenciada por um processo sem privilégio. Essa condição fornece uma primitiva pequena de escrita, comparável no efeito operacional a classes anteriores como Dirty Pipe e Copy Fail.
A falha em xfrm-ESP tem uma restrição importante: o explorador normalmente precisa criar um namespace para alcançar a interface necessária. Em distribuições que permitem essa criação para usuários sem privilégio, a variante associada a ESP pode ser suficiente para iniciar a cadeia. Em ambientes onde a criação de namespace é bloqueada, como configurações do Ubuntu protegidas por AppArmor, esse caminho específico fica impedido. Dirty Frag amplia a confiabilidade ao combinar a segunda variante, em RxRPC, que não exige a mesma permissão de criação de namespace, embora dependa da presença do módulo rxrpc.ko no sistema.
A variante RxRPC cobre parte da superfície deixada pela restrição de namespace. Em algumas distribuições, como builds padrão de RHEL 10.1, rxrpc.ko pode não estar presente. Em outras, como Ubuntu, o módulo pode estar compilado e carregado por padrão. A cadeia escolhe o caminho viável conforme a configuração: quando namespaces de usuário estão disponíveis, o fluxo em ESP tende a ser acionado primeiro; quando essa criação está bloqueada, mas rxrpc.ko está presente, o caminho em RxRPC fornece a rota alternativa. O resultado prático é uma cadeia menos dependente de uma configuração única e com maior chance de funcionar em famílias diferentes de Linux.
O impacto técnico não se limita à escrita abstrata em memória. A corrupção de páginas apoiadas pelo cache pode permitir alteração de conteúdo sensível usado pelo sistema para tomada de decisão, inclusive arquivos e estruturas que influenciam autenticação, permissões ou execução. O material analisado também descreve prova de conceito pública capaz de obter root em um único comando, o que reduz a barreira para reprodução por operadores ofensivos e por equipes de validação. A confiabilidade é um fator de risco adicional: uma falha que não depende de corrida, não costuma derrubar o núcleo quando falha e apresenta alta taxa de sucesso tende a ser incorporada rapidamente a cadeias pós-exploração.
A superfície principal está em hosts Linux cujo núcleo contém os caminhos vulneráveis e expõe os módulos ou interfaces necessários. A falha em xfrm-ESP está ligada ao subsistema IPsec xfrm, incluindo caminhos de esp4 e esp6. A falha em RxRPC depende do módulo rxrpc.ko. A introdução histórica dos defeitos também difere: a condição relacionada a xfrm-ESP deriva de alteração de código feita em janeiro de 2017, enquanto a condição em RxRPC deriva de mudança de junho de 2023. Essa diferença explica por que sistemas com bases de núcleo e opções de build distintas podem apresentar comportamentos de exploração diferentes.
Distribuições citadas como alvos onde a exploração foi demonstrada ou indicada incluem Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10 e Fedora 44. A presença em uma lista de distribuições não substitui inventário local: equipes devem confirmar a versão exata do pacote de núcleo, os patches backportados pelo fornecedor, a configuração de namespaces de usuário, a presença de AppArmor ou seccomp e o estado de carregamento dos módulos afetados. Backports podem alterar a exposição sem mudar de forma óbvia a versão de base exibida por comandos simples.
Em hosts sem contêineres, a pré-condição crítica é o invasor já possuir execução local como usuário não privilegiado. Esse acesso pode vir de credenciais fracas, serviço comprometido, conta de aplicação, shell obtido por exploração remota ou execução de binário em diretório gravável. Em clusters e plataformas de contêiner, a análise deve considerar cargas que executam código arbitrário, permissões concedidas ao contêiner, perfis seccomp, capacidades Linux, montagem de volumes e restrições de namespace. Configurações endurecidas de Kubernetes com perfis padrão podem reduzir caminhos de exploração, especialmente quando capacidades de rede elevadas, como CAP_NET_ADMIN, não estão disponíveis.
A atividade observada em campo é limitada, mas material para defesa. O fluxo descrito começa por uma conexão externa que obtém acesso via SSH, abre shell interativo, prepara e executa um ELF chamado ./update e em seguida aciona escalonamento por su. Após obter privilégio elevado, os operadores analisam diretórios e configuração de GLPI, modificam arquivo de autenticação LDAP do GLPI, acessam dados sensíveis e interagem com múltiplos arquivos de sessão PHP, incluindo remoção e sobrescrita forçada de alguns deles. Esses elementos não provam que todo uso de su ou todo binário update esteja ligado a Dirty Frag, mas formam uma sequência útil para investigação quando combinados com sinais de acesso inicial e mudança de privilégio.
- Hosts Linux com módulos
esp4,esp6ourxrpcdisponíveis ou carregados devem ser priorizados para validação de exposição. - Ambientes que permitem criação de namespaces por usuários sem privilégio ficam mais expostos ao caminho
xfrm-ESP. - Sistemas Ubuntu com bloqueio de namespace por AppArmor ainda podem ficar expostos quando
rxrpc.koestá presente e carregado. - Servidores com GLPI e acesso
SSHexterno merecem revisão adicional quando houver execução recente de ELF desconhecido e uso anômalo desu.
A investigação deve começar por eventos de acesso local que precedem elevação de privilégio. Em servidores, correlacione autenticações SSH recentes, criação de shell interativo, gravação de binários em diretórios temporários ou de aplicação, execução de arquivos ELF recém-criados e chamadas subsequentes a su. A presença de um arquivo chamado ./update não é indicador suficiente isoladamente, mas se torna relevante quando aparece em sequência com conexão remota, alteração de usuário, execução a partir de diretórios incomuns e atividade administrativa sem mudança autorizada. Quando possível, cruze logs de autenticação, auditoria de processo, EDR, histórico de shell e eventos de integridade de arquivo.
No núcleo e na superfície de módulos, valide se esp4, esp6 e rxrpc foram carregados em janelas próximas a eventos suspeitos. Em Linux, dados de lsmod, histórico de modprobe, mensagens de dmesg, logs do sistema e telemetria eBPF podem ajudar a identificar carregamento dinâmico ou uso incomum. Ambientes com auditoria devem observar chamadas a unshare, criação de namespaces, uso de interfaces netlink relacionadas a XFRM, manipulação de sockets e fluxos que envolvem splice(2), sendfile(2) ou MSG_SPLICE_PAGES. Esses sinais precisam ser avaliados por contexto, pois servidores legítimos de rede e aplicações de alto desempenho podem usar parte dessas primitivas.
Para GLPI, procure alterações recentes em arquivos de autenticação LDAP, leitura ou modificação incomum de diretórios de configuração, acesso em massa a arquivos PHP de sessão e remoção seguida de sobrescrita forçada de sessões. A sequência descrita sugere tentativa de obter dados sensíveis, interferir em sessões ativas ou reduzir rastros operacionais. A investigação deve preservar cópias forenses antes da limpeza, pois arquivos de sessão e logs de aplicação podem conter carimbos de tempo, identificadores de usuário e rotas acessadas. Também é importante revisar se o privilégio elevado foi usado para criar novas contas, alterar chaves SSH, adicionar tarefas agendadas ou modificar serviços persistentes.
Em plataformas de contêiner, o hunting deve incluir eventos de execução de processos privilegiados dentro de pods, tentativas de criação de namespaces, uso incomum de capacidades de rede, montagem de caminhos do host e cargas que executam binários baixados em tempo de execução. A falta de evidência de exploração não elimina risco quando os logs não capturam chamadas de sistema ou quando o host não possui telemetria de processo. Para ambientes críticos, uma validação controlada de exposição, feita em laboratório com a mesma versão do núcleo e a mesma política de módulos, é mais confiável do que inferir segurança apenas por família de distribuição.
- Autenticação
SSHseguida de shell interativo, gravação de ELF local e execução desuem curto intervalo. - Criação de namespaces por usuário sem privilégio, uso de
XFRMvia netlink ou carregamento recente deesp4,esp6erxrpc. - Execução de binário chamado
./updateem diretório não padronizado, especialmente quando acompanhado de mudança imediata pararoot. - Modificação de arquivo de autenticação LDAP do GLPI e acesso, remoção ou sobrescrita de arquivos de sessão PHP.
- Mudanças pós-elevação em chaves SSH, contas locais, serviços systemd, tarefas agendadas e permissões de diretórios de aplicação.
A medida principal é instalar núcleos corrigidos fornecidos pela distribuição ou compilar versões que contenham as correções equivalentes aos commits f4c50a4034e6 e aa54b1d27fe0. Como fornecedores podem aplicar backports sem alterar imediatamente a numeração de versão esperada, a validação deve consultar os avisos e changelogs do pacote instalado, não apenas a saída genérica de versão do núcleo. Após atualização, reinicie os hosts ou aplique o mecanismo operacional equivalente para garantir que o núcleo corrigido esteja em execução. Sistemas que apenas instalaram o pacote, mas continuam inicializados no núcleo antigo, permanecem expostos.
Até a atualização completa, bloqueie o carregamento de esp4, esp6 e rxrpc quando esses módulos não forem necessários para a operação. A decisão exige teste prévio: esp4 e esp6 podem afetar uso de IPsec, enquanto rxrpc pode impactar componentes que dependem desse protocolo. O bloqueio deve ser acompanhado de verificação de módulos já carregados, pois impedir carregamento futuro não remove automaticamente código em uso. Também revise políticas que permitem criação de namespaces por usuários sem privilégio e reduza essa permissão quando não houver dependência operacional legítima.
Em contêineres, reduza a exposição removendo capacidades desnecessárias, evitando CAP_NET_ADMIN por padrão, mantendo perfis seccomp restritivos e impedindo cargas de trabalho não confiáveis de alcançar interfaces de núcleo fora do necessário. Pods privilegiados, montagens amplas do host e imagens que executam código de terceiros devem receber prioridade de revisão. Em servidores de aplicação, especialmente onde houve acesso SSH externo ou GLPI instalado, combine a atualização do núcleo com rotação de credenciais potencialmente expostas, revisão de sessões, restauração de arquivos alterados a partir de fonte confiável e busca por persistência.
A resposta a incidente deve tratar Dirty Frag como uma falha de pós-exploração. Se há indício de uso da cadeia, não basta aplicar patch. Preserve evidências, isole o host quando possível, colete logs de autenticação e processo, inventarie binários gravados recentemente, revise contas e chaves autorizadas, verifique integridade de pacotes e compare arquivos de configuração críticos com baselines. Quando GLPI estiver envolvido, invalide sessões, revise integrações LDAP, audite contas administrativas e confirme se arquivos PHP de sessão não foram usados para extrair dados. Encerrar a investigação sem essa etapa pode deixar uma intrusão com privilégio root persistente mesmo após a correção do núcleo.
- Atualizar o núcleo para pacote que contenha correções de
CVE-2026-43284eCVE-2026-43500, depois reiniciar no núcleo corrigido. - Bloquear
esp4,esp6erxrpcquando a função não for necessária, validando impacto em IPsec, aplicações e dependências do host. - Restringir criação de namespaces por usuários sem privilégio e revisar AppArmor, seccomp e capacidades Linux em servidores e contêineres.
- Procurar e remover binários desconhecidos como
./updatesomente após coleta forense suficiente. - Rotacionar credenciais e invalidar sessões quando houver sinais de acesso a GLPI, LDAP, arquivos PHP de sessão ou execução com
rootnão autorizada.
0 Comentários