DirtyClone: a vulnerabilidade do kernel Linux que permite escalar privilégios sem tocar o disco

Um novo exploit de escalada de privilégios chamado DirtyClone(CVE-2026-43503, CVSS 8.8) volta a evidenciar uma mesma fraqueza arquitetural no subsistema de rede do kernel Linux: a otimização de zero-copia que permite tratar páginas de arquivo como dados de pacotes pode se transformar em uma primitiva de escrita se em algum ponto do código se perde uma bandeira de segurança. JFrog Security Research publicou uma demonstração funcional em 25 de junho que mostra como um atacante local pode corromper memória apoiada por arquivo e, sem tocar no disco, conseguir root substituindo bytes de um binário privilegiado em memória (por exemplo /usr/bin/su) e provocando sua execução posterior com privilégios elevados.

O vetor concreto de DirtyClone explora que duas funções auxiliares envolvidas quando o kernel clona um pacote de rede deixam de espalhar o bit que marca fragmentos compartilhados com o sistema de arquivos. O exploit encadeia a colocação de páginas de um binário privilegiado dentro de um skb (socket buffer), a clonagem desse skb e sua passagem por um túnel IPsec controlado pelo atacante: durante a descompressão/desencriptado na rota de recepção o kernel sobresscreve a memória mapeada com dados controlados pelo atacante. O arquivo em disco não é modificado, as ferramentas de integridade de arquivos não detectam nada e um reinício restaura a imagem em disco; em outras palavras, a modificação é temporária, mas suficiente porque o atacante já tem root antes que alguém o note.

É importante entender onde aplicam as limitações práticas: a exploração requer a capacidade CAP_NET_ADMIN para configurar o túnel loopback IPsec. Em distribuições que permitem a criação de user namespaces sem privilégios (por exemplo Debian e Fedora com configuração predefinida) um utilizador local pode obter CAP_NET_ADMIN dentro de um namespace e assim montar a rota de exploração. Ubuntu 24.04 e posteriores têm endurecido a criação de namespaces através do AppArmor, o que bloqueia a via de exploração por defeito nessa plataforma.

DirtyClone não é um caso isolado: é a quarta variante em semanas que aproveita a mesma falha de contrato no manejo de fragmentos skb. Copy Fail, DirtyFrag e Fragnesia foram variantes anteriores que encontraram outras funções onde não se respeitava a mesma regra: Cada caminho que mova descritores de fragmento deve preservar o bit shared-frag. O adesivo combinado que sellou múltiplos pontos fracos foi integrado em mainline em 21 de maio (commit 48f6a5356a33) e foi retroportado a ramos estáveis e LTS; no entanto, a presença reiterada de variantes indica que a superfície continua a ser ampla e requer auditoria exaustiva.

Acções imediatas e práticas a tomar pelos administradores: atualizar o kernel Quanto antes de uma versão com o adesivo aplicado (a correção está em Linux v7.1-rc5 e em backports estáveis/LTS). Após o adesivo, reinicie os sistemas afectados: uma vez que a exploração altera apenas a memória ao vivo, um reinício limpo das alterações temporárias e fecha o vetor activo de uma intrusão recente. Veja o registro oficial do kernel para o commit da correção: commit 48f6a5356a33 e detalhes CVE na base NVD: CVE-2026-43503.

Se não puder colocar o adesivo de imediato, existem duas mitigações temporárias que reduzem a superfície de ataque: desativar a criação de user namespaces sem privilégios (no Debian e Ubuntu pode ser feita com o kernel.unprivileged_userns_clone=0 através do sysctl ou /etc/sysctl.conf) e/ou bloquear os módulos do kernel envolvidos (esp4, esp6 e rxrpc) adicione-os à lista negra do modprobe. Ambas as medidas têm impacto funcional —bloquear esp* deshabilita IPsec e o blacklisting só funciona se esses componentes são módulos e não estão compilados no kernel — então devem ser aplicados com conhecimento do ambiente. Estas atenuações não substituem a atualização completa do kernel.

Os ambientes mais expostos são aqueles multi-tenant ou que permitem a usuários não confiáveis criar namespaces e manipular a rede: servidores públicos, runners de CI compartilhados, hosts de contêineres e clusters Kubernetes com políticas laxas. Nestes cenários, convém aplicar controlos adicionais: minimizar as capacidades concedidas a contentores (não conceder CAP_NET_ADMIN, salvo necessidade, usar perfis de seccomp/SELinux/AppArmor), restringir quem pode criar namespaces e rever a configuração do runtime de contentores para evitar vazamento por capacidades de rede.

De uma perspectiva de defesa e gestão do risco, há duas mensagens claras. Primeiro, a classe de falhas que o DirtyClone provoca é uma vulnerabilidade de contrato entre componentes do kernel: a solução não é apenas patchar funções concretas, mas auditar e reforçar a invariancia em todo o código que move fragmentos skb. Segundo, para operadores a detecção é difícil porque as mudanças não tocam o disco nem deixam rastros nas integridades de arquivos; por isso, a resposta ante a suspeita de compromisso deve incluir atualização + reinício e, em casos razoáveis, reconstrução de imagens confiáveis. Mantenha processos de adesivo acelerado para kernels e verifique políticas de isolamento para usuários e cargas de trabalho.

Finalmente, os equipamentos de segurança e de plataforma devem monitorizar os avisos da sua distribuição e aplicar os adesivos e backports que publiquem os vendors; além disso, avaliar os controlos preventivos a nível de política de contentores e a capacidade de detecção de atividade anómala na rede interna. A recorrência de variantes no mesmo "family bug" é uma chamada a reforçar tanto o processo de desenvolvimento do kernel como as estratégias de defesa em profundidade em infraestruturas compartilhadas.