linnemanlabs/dirtyfrag-arm64Port do V4bel/dirtyfrag para arm64/aarch64 (CVE-2026-43284). Apenas ESP - o caminho rxrpc causa oops do kernel em arm64 devido a flush_dcache_page
Porte arm64/aarch64 de V4bel/dirtyfrag (CVE-2026-43284, CVE-2026-43500).
Testado em Ubuntu 24.04.4 LTS com linux-aws 6.17.0-1013-aws em AWS Graviton (o mais recente disponível até a data desta escrita).
Análise completa com análise de bypass do AppArmor, notas de hardening e notas de detecção: linnemanlabs.com/posts/porting-dirtyfrag-arm64
O Ubuntu tem dois sysctls do AppArmor:
Ambos podem ser contornados encadeando aa-exec com ele mesmo usando perfis presentes nas imagens padrão de cloud e do instalador do Ubuntu que testei:
aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp
Para mais informações, veja Two Hops and a Shell para a análise completa do bypass do AppArmor do Ubuntu.
O PoC upstream x86_64 usa dois caminhos de exploração: um caminho ESP/xfrm que corrompe /usr/bin/su, e um fallback rxrpc/rxkad que corrompe /etc/passwd. No arm64, o caminho rxrpc causa oops no kernel e não pode ser usado. O caminho ESP funciona corretamente.
flush_dcache_pageNo x86_64, flush_dcache_page() é um no-op. O x86 tem caches de dados/instruções coerentes por hardware. No arm64, ele realiza manutenção real de dcache e desreferencia os metadados struct page*. Quando o caminho criptográfico do rxrpc (rxkad_secure_packet -> crypto_pcbc_encrypt -> skcipher_walk_done) chama flush_dcache_page em uma página cuja referência foi manipulada por meio da cadeia splice/vmsplice, o x86_64 a ignora silenciosamente, mas o arm64 atinge uma falha de tradução e causa oops:
pc : flush_dcache_page+0x18/0x58
lr : skcipher_walk_done+0xbc/0x260
crypto_pcbc_encrypt+0xe8/0x1c8 [pcbc]
crypto_skcipher_encrypt+0x48/0xb8
rxkad_secure_packet+0x108/0x270 [rxrpc]
rxrpc_send_data+0x264/0x550 [rxrpc]
Nos sistemas arm64 que testei, negar a escrita em uid_map removeu o caminho ESP funcional. O namespace ainda pode ser criado, mas o processo não pode se mapear para root dentro dele nem obter as capabilities do namespace necessárias para a configuração do XFRM. O fallback rxrpc não forneceu um caminho funcional de escalonamento de privilégios sem namespace no arm64; em vez disso, causou oops no kernel.
No arm64, apenas o caminho ESP foi viável nos meus testes. Esse caminho exige a criação de um namespace de usuário e de rede e, em seguida, o mapeamento bem-sucedido do usuário que chama para root dentro desse namespace. O hardening da distribuição pode quebrar esse caminho de diferentes maneiras: o Ubuntu pode negar a escrita em uid_map por meio das restrições de userns do AppArmor; não testei no Debian/RHEL.
Na imagem AWS do Ubuntu 24.04 que testei, apparmor_restrict_unprivileged_userns=1 bloqueou a exploração direta do meu shell SSH normal ao negar a escrita em uid_map dentro do novo namespace.
No entanto, com o padrão apparmor_restrict_unprivileged_unconfined=0, um usuário não confinado pode fazer a transição para um perfil existente em modo complain (ex.: runc) via aa-exec e contornar a restrição:
aa-exec -p runc -- ./dirtyfrag_arm64 --force-esp
Definir kernel.apparmor_restrict_unprivileged_unconfined=1 bloqueia esse caminho e é amplamente recomendado atualmente como solução para bloquear todos os caminhos. No entanto, adicionar outro aa-exec também contorna isso:
aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp
Consulte os posts vinculados anteriormente para obter detalhes.
O exploit sobrescreve /usr/bin/su no page cache com um ELF estático mínimo. O PoC upstream incorpora um ELF x86_64 com shellcode x86_64. Este porte o substitui por um ELF aarch64 equivalente:
e_machine: EM_AARCH64 (183) em vez de EM_X86_64 (62)svc #0 em vez de syscall# Clone
git clone https://github.com/linnemanlabs/dirtyfrag-arm64.git
# Build
cd dirtyfrag-arm64
gcc -O0 -Wall -o dirtyfrag_arm64 dirtyfrag_arm64.c -lutil
# Run
./dirtyfrag_arm64 --force-esp
A flag --force-esp pula o caminho rxrpc inteiramente para garantir a prevenção do oops do kernel no arm64.
Em 2026-05-09, o kernel aws do Ubuntu 24.04 mais recente disponível (6.17.0-1013-aws, compilado em 24 de abril) é distribuído sem correções para Copy Fail (CVE-2026-31431, divulgado em 29 de abril) ou Dirty Frag (CVE-2026-43284/43500, divulgado em 7 de maio).
Coloque na blacklist os módulos vulneráveis e aplique o hardening de sistema adequado à sua distribuição.
Seguro em qualquer sistema que não esteja usando ativamente o modo de transporte IPsec ou AFS. Para evitar o carregamento dos módulos, coloque o seguinte em /etc/modprobe.d/dirtyfrag.conf:
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
O Ubuntu também recomenda regenerar o initramfs para que a blacklist esteja presente durante o boot inicial:
update-initramfs -u -k all
``
### Remover permissões de leitura dos binários SUID
Bloqueia essa classe de ataque baseada em splice ao page cache contra esses binários SUID alvo. O exploit precisa de permissões de leitura no arquivo alvo para `splice()`. Os usuários ainda podem executar os binários.
**Não implemente isto sem testar no seu ambiente e em todas as suas ferramentas.**
```bash
chmod o-r /usr/bin/su
Isto não é uma correção, apenas uma mitigação. Existem muitos outros caminhos para escalonamento de privilégios.
Para descarregar os módulos do sistema em execução:
rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null
Certifique-se de que eles estão descarregados:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
&& echo "Affected modules are loaded" \
|| echo "Affected modules are NOT loaded"
Limpar o page cache deve remover os conteúdos maliciosos e fazer com que os arquivos sejam lidos do disco novamente.
echo 3 > /proc/sys/vm/drop_caches
Nota: tive alguns resultados inconsistentes com isso, mas quanto mais tento reproduzir, mais está funcionando como esperado. Para este PoC, você pode verificar o md5sum em /usr/bin/su e, se não corresponder, reinicie.
Execute a etapa de limpeza do page cache e depois verifique com:
sha256sum /usr/bin/su
# Or from package manager:
dpkg -V util-linux # Debian/Ubuntu
rpm -V util-linux # RHEL/Amazon Linux
Para uma postura mais proativa que aborde toda essa classe de vulnerabilidades (não apenas os CVEs específicos), consulte a análise completa sobre restrições de userns do AppArmor, prevenção de pré-carregamento de módulos e detecção em tempo de execução baseada em Tetragon, bem como regras YARA.
flush_dcache_page, pesquisa sobre AppArmor, notas de detecçãoEsta ferramenta destina-se apenas a testes de segurança autorizados e pesquisa.
O uso não autorizado contra sistemas que você não possui ou para os quais não tem permissão explícita para testar é ilegal e antiético.
MIT. Copie, roube, modifique, aprenda com ele, compartilhe suas melhorias comigo. Ou não. É código, faça o que quiser com ele.
| Propriedade | Valor |
|---|
| Instância | AWS t4g.micro (Graviton2) |
| SO | Ubuntu 24.04.4 LTS |
| Kernel | 6.17.0-1013-aws #13~24.04.1-Ubuntu (compilado em 2026-04-24) |
| Arquitetura | aarch64 |
unprivileged_userns_clone | 1 (ativado) |
| módulo esp4 | disponível, carregável |
| módulo rxrpc | disponível, carregável (mas falha no arm64) |
| Configuração | imagem de cloud padrão do ubuntu 24.04, módulos de kernel padrão |