Dirty Frag (CVE-2026-43284): a falha no kernel do Linux que transforma o acesso de leitura em acesso de root

Um ficheiro de leitura apenas deve permanecer como tal. A vulnerabilidade «Dirty Frag» (CVE-2026-43284, CVE-2026-43500 e CVE-2026-46300) leva o kernel do Linux a editar, de todo, a sua cópia em cache.

Esta falha permite que um programa em execução com quase nenhum privilégio escreva em ficheiros que deveria apenas poder ler, alterando a cópia que o kernel mantém na memória. A partir daí, pode reescrever algo em que o sistema confia e conceder a si próprio acesso de root. Em ambientes «container », o mesmo truque que atinge o kernel do anfitrião pode atingir o kernel do nó partilhado por todas as cargas de trabalho.

A falha de segurança está presente no código de rede do kernel há anos, razão pela qual afeta a maioria das versões do kernel suportadas e praticamente todas as principais distribuições. O Linux corrigiu a falha e todas as distribuições aplicaram a correção retroativamente, pelo que a correção terá um número de versão diferente em cada uma delas.

Visão geral do Dirty Frag

A Red Hat agrupa três CVEs sob o nome «Dirty Frag». Estes encontram-se em diferentes partes do código de rede do kernel, sendo que um deles é uma variante posterior que não foi abrangida pela primeira ronda de correções. Eis uma comparação entre eles.

O subsistema indica-lhe se isto é relevante para si. Se não utilizar VPNs IPsec nem AFS, é uma indicação rápida do grau de importância que deve atribuir a esta questão. O módulo é o que deverá verificar (lsmod | grep -E 'esp4|esp6|rxrpc') para ver o que está carregado.

O Linux mantém os dados dos ficheiros acedidos recentemente na memória, para não ter de os ler do disco de cada vez. Essa cópia na memória é designada por cache de páginas. Certas funções do kernel, como splice() passar esses dados armazenados em cache para o código de rede sem os copiar, mas sim fornecendo um ponteiro para o local onde os dados já se encontram. Isso poupa trabalho, desde que cada etapa subsequente saiba que a memória é partilhada e não escreva nessa memória.

O erro surgiu em duas partes distintas do código de rede do kernel. Uma delas era o ESP, que gere o tráfego VPN encriptado. A outra era o RxRPC, um protocolo mais antigo utilizado principalmente pelo sistema de ficheiros AFS. Nem o ESP nem o RxRPC verificam se a memória é partilhada antes de gravarem nela.

Isto permitia que um atacante obtivesse um ficheiro de leitura exclusiva que, se fosse adulterado, lhe poderia conferir privilégios, algo como /usr/bin/su, e introduzir o seu conteúdo no caminho de rede, de modo a que a descriptografia com erros acabasse por gravar na memória desse ficheiro. A gravação acaba por ir para a cache de páginas, que é a cópia do ficheiro que o sistema disponibiliza a qualquer entidade que o leia. O ficheiro no disco nunca se altera, mas a versão na memória apresenta agora o conteúdo que o atacante fez com que aparecesse. Ao executar o comando «su», o sistema lê a cópia adulterada e concede ao atacante acesso de root, apesar de este ter tido, desde o início, apenas permissão para ler esse ficheiro.

A Fragnesia, registada como CVE-2026-46300, é a variante mais recente. A correção do «Dirty Frag» fez com que o kernel passasse a basear-se num marcador que indica: «este fragmento é partilhado; faça uma cópia segura antes de o alterar». No entanto, um bug antigo de 2013 no código que une fragmentos de pacotes elimina silenciosamente esse marcador. Este bug permaneceu inofensivo durante treze anos, uma vez que nada dependia dele. Infelizmente, a correção do «Dirty Frag» dependia dele, o que transformou um bug adormecido numa nova via de acesso ao root. 

Por que é que o «Dirty Frag» é importante para os contentores?

Todos os contentores partilham um único kernel com o anfitrião, pelo que um « container » (processo malicioso) pode aceder ao código vulnerável do kernel, caso as suas permissões o permitam (configurações de chamadas de sistema, namespace e política de segurança). Os investigadores já publicaram exploits de prova de conceito funcionais para o Kubernetes, e a Ubuntu explica detalhadamente o risco de um « container » (ataque de injeção de código)escape. Se o « container » (processo malicioso) conseguir aceder ao kernel, o risco é o acesso de root em todo o nó.

É possível neutralizar partes do ataque executando cargas de trabalho sem privilégios de root, ativando o perfil seccomp «RuntimeDefault», aplicando políticas restritivas aos pods e limitando os espaços de nomes de utilizadores sem privilégios. No entanto, nenhuma destas medidas corrige a falha propriamente dita. Apenas a atualização do kernel fornecida pelo fabricante o faz.

Como é que se pode saber se um anfitrião está exposto?

Começa pelo host que está efetivamente a funcionar, e não pelo Dockerfile. Há três comandos que te ajudam.

Execute uname -r Para saber qual é a versão do kernel que está a utilizar, compare-a com a versão corrigida indicada no aviso da sua distribuição. Não a compare com o número do upstream. O padrão vulnerável remonta a kernels de cerca de 2017, e as distribuições empresariais e LTS, como o RHEL, o Ubuntu e o Debian, aplicam a correção retroativamente à versão mais antiga do kernel que já utiliza; por isso, um kernel corrigido pode continuar a indicar uma versão de há vários anos. Um host RHEL 8 totalmente corrigido continua a indicar a versão 4.18, e essa versão 4.18 já inclui a correção. Confirme a versão do pacote corrigido junto do seu fornecedor.

lsmod | grep -E 'esp4|esp6|rxrpc' indica se o caminho de código vulnerável está carregado. Um resultado vazio não significa que não haja risco, uma vez que estes módulos são carregados à medida que são solicitados. E o facto de estar carregado não significa automaticamente que seja prejudicial. O esp4, o esp6 e o rxrpc são módulos comuns que são perfeitamente seguros num kernel com patches aplicados. Isto permite-lhe conhecer a sua superfície de ataque e saber se vale a pena aplicar a medida de mitigação da lista negra.

sysctl user.max_user_namespaces mostra o grau de acessibilidade do caminho ESP. Um valor acima de zero significa que os utilizadores sem privilégios podem criar espaços de nomes, o que constitui a via habitual de acesso ao caminho ESP. O valor zero bloqueia essa possibilidade, mas apenas para o ESP. O caminho RxRPC não necessita de espaços de nomes, pelo que esta medida não oferece proteção total.

Verifique o estado do seu fornecedor. A Red Hat afirma que o CVE-2026-43500 não afeta os seus produtos, enquanto que o CVE-2026-43284 e o CVE-2026-46300 afetam os kernels do Red Hat Enterprise Linux suportados e tudo o que for construído com base neles. O Ubuntu publica a versão exata do pacote corrigido para cada linha de kernel que suporta.

O que deve monitorizar?

O código de prova de conceito já se encontra disponível ao público. A Microsoft comunicou que a atividade no mundo real tem sido limitada em que um atacante obtém privilégios superiores utilizando su, embora seja importante ter em conta que pode tratar-se do «Dirty Frag» ou do seu antecessor, o «Copy Fail», uma vez que é difícil distinguir os dois apenas a partir dos registos de processo.

A forma mais realista de detetar isto é através das ferramentas de auditoria e EDR que já utiliza. A estrutura de auditoria do Linux pode registar a execução de processos e as transições setuid, sendo aí que a sequência reveladora viria a surgir: um ficheiro binário desconhecido a ser colocado e executado, seguido imediatamente por su. Esteja atento ao carregamento do esp4, esp6 ou rxrpc por volta da altura em que ocorrerem outras atividades suspeitas, especialmente num host que não tenha motivos para utilizar o IPsec ou o AFS, e à execução de ficheiros ELF recém-transferidos. 

Se suspeitar de exploração, execute as suas verificações de integridade a partir de um ambiente fiável, em vez de o fazer a partir do próprio anfitrião, que pode estar comprometido. E lembre-se de que bloquear os módulos do kernel não anula quaisquer alterações ao cache de páginas que um atacante já tenha feito.

O papel da « Aikido »

Na maioria das vezes, a análise fica-se pela imagem ou pelo repositório. O Dirty Frag encontra-se um nível abaixo, no kernel onde o nó é efetivamente inicializado.

Aikido O Security varredura de máquinas virtuais analisa o que está efetivamente instalado no anfitrião em execução a partir de um instantâneo na nuvem, pelo que um pacote do kernel vulnerável aparece como um resultado da análise do anfitrião. Como também associa os anfitriões às cargas de trabalho e às contas que neles estão a ser executadas, é possível avaliar o alcance do impacto caso um nó seja comprometido.

Para os servidores na nuvem ligados a Aikido, o varredura de máquinas virtuais identifica aqueles que contêm o pacote do kernel vulnerável e mostra quais as cargas de trabalho que neles são executadas. A correção é a mesma: aplicar o patch ao kernel do nó e confirmar a versão carregada após o reinício.

{{cta}}

FAQ