Nenhum dos bugs isoladamente é totalmente confiável — o caminho ESP exige a capacidade de criar um namespace de usuário (que o AppArmor do Ubuntu bloqueia), e o caminho RxRPC precisa do rxrpc.ko carregado (o que a maioria das distribuições não faz por padrão). Juntos, eles cobrem os pontos cegos um do outro, tornando a cadeia funcional em praticamente todas as principais distribuições.

Uma prova de conceito pública está disponível. Considere que ela já está em uso ativo.

O que este script faz

Ele verifica seu sistema quanto às condições que tornam a exploração possível e informa especificamente por que você está exposto — não apenas um sim ou não.

Ele não corrige nada. Ele não explora nada. Ele apenas informa a verdade sobre o seu sistema.

Requisitos

• Python 3.6+
• Sem dependências externas — apenas stdlib
• Sem necessidade de root (intencionalmente — verificamos o que um atacante sem privilégios pode ver)

Uso

Só isso. Saída com código de cores, motivos específicos para cada descoberta e um resumo de remediação no final.

Captura de tela

[]

Corrigindo

A correção real é atualizar seu kernel. Verifique os avisos de segurança da sua distribuição:

Enquanto você espera (ou se os patches ainda não estiverem disponíveis para sua distribuição), coloque os módulos vulneráveis na blacklist:

⚠️ Antes de fazer isso:

• Colocar esp4/esp6 na blacklist quebrará túneis IPsec (strongSwan, Libreswan; WireGuard não é afetado). Não aplique isso em gateways VPN.
• Colocar rxrpc na blacklist quebrará clientes do sistema de arquivos distribuído AFS. Quase ninguém usa isso — mas verifique primeiro.

Importante: se o seu sistema pode ter sido alvo antes da mitigação ser aplicada, o exploit pode modificar binários no cache de páginas sem tocar no disco. Ferramentas de integridade de arquivos (Tripwire, AIDE) que verificam checksums no disco não verão nada errado. Reiniciar limpa o cache de páginas e restaura o estado no disco.

Como funciona (a versão curta)

Ambos os bugs vivem nos caminhos rápidos de descriptografia in-place do kernel. Quando um buffer de socket carrega fragmentos paginados que não são de propriedade privada do kernel — por exemplo, páginas de pipe anexadas via splice() ou sendfile() — os caminhos de recebimento ESP e RxRPC descriptografam diretamente sobre essas páginas com suporte externo, em vez de copiar primeiro.

Um atacante pode direcionar uma página do cache de /usr/bin/su (ou qualquer outro arquivo legível) para um desses caminhos de descriptografia, usando sua própria chave para que a "saída descriptografada" sejam os bytes que ele escolher. O kernel escreve esses bytes diretamente na cópia em cache na memória do su. O arquivo no disco não é tocado. O kernel nunca marca a página como suja.

A partir desse ponto, todo processo que executa su roda a versão do atacante — até drop_caches ou uma reinicialização.

A variante ESP (cac2661c53f3) e a variante RxRPC (2dc334f1a63a) compartilham o mesmo destino, mas têm pré-requisitos diferentes que se cancelam, tornando a cadeia confiável em todas as principais configurações.

Para o relatório técnico completo, veja V4bel/dirtyfrag.

Linha do tempo da divulgação

Crédito: Hyunwoo Kim (@v4bel) pela pesquisa original, divulgação e PoC.

Aviso legal

Apenas detecção. Aponte-o para sistemas que você está autorizado a avaliar.