No-exec / NX

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Informazioni di base

Il bit No-Execute (NX), noto anche come Execute Disable (XD) nella terminologia Intel, è una funzionalità di sicurezza basata su hardware progettata per attenuare gli effetti degli attacchi buffer overflow. Quando implementata e abilitata, distingue tra regioni di memoria destinate al codice eseguibile e quelle destinate ai dati, come lo stack e l’heap. L’idea principale è impedire a un attaccante di eseguire codice malevolo tramite vulnerabilità di buffer overflow mettendo ad esempio il codice malevolo nello stack e dirigendo il flusso di esecuzione verso di esso.

I sistemi operativi moderni applicano NX tramite gli attributi della page table che supportano gli header del programma ELF. Per esempio, l’header PT_GNU_STACK combinato con le proprietà GNU_PROPERTY_X86_FEATURE_1_SHSTK o GNU_PROPERTY_X86_FEATURE_1_IBT indica al loader se lo stack debba essere RW o RWX. Quando NX è abilitato e il binario è stato linkato con uno stack non eseguibile (-z noexecstack), qualsiasi tentativo di pivotare l’esecuzione verso pagine di dati controllate dall’attaccante (stack, heap, mmap’ed buffers, ecc.) genererà un fault a meno che quelle pagine non siano state esplicitamente marcate come eseguibili.

Rilevare NX rapidamente

  • checksec --file ./vuln mostrerà NX enabled o NX disabled in base all’header del programma GNU_STACK.
  • readelf -W -l ./vuln | grep GNU_STACK espone i permessi dello stack; la presenza di un flag E indica che lo stack è eseguibile. Esempio:
$ readelf -W -l ./vuln | grep GNU_STACK
GNU_STACK      0x000000 0x000000 0x000000 0x000000 0x000000 RW  0x10
  • execstack -q ./vuln (from prelink) è utile quando si auditano grandi raccolte di binari perché stampa X per i binari che hanno ancora uno stack eseguibile.
  • Durante l’esecuzione, /proc/<pid>/maps mostrerà se un’allocazione è rwx, rw-, r-x, ecc., il che è utile quando si verificano JIT engines o custom allocators.

Tecniche di bypass

Primitive di riuso del codice

È possibile utilizzare tecniche come ROP per aggirare questa protezione eseguendo porzioni di codice eseguibile già presenti nel binario. Catene tipiche includono:

  • Ret2libc
  • Ret2syscall
  • Ret2dlresolve quando il binario non importa system/execve
  • Ret2csu o Ret2vdso per sintetizzare syscall
  • Ret2… — qualsiasi dispatcher che ti permette di combinare lo stato dei registri controllati con codice eseguibile esistente per invocare syscall o gadget di libreria.

Il flusso di lavoro è solitamente: (1) leak un puntatore al codice o a libc tramite un info leak, (2) risolvere le basi delle funzioni, e (3) costruire una chain che non richieda mai byte eseguibili controllati dall’attaccante.

Sigreturn Oriented Programming (SROP)

SROP costruisce un falso sigframe su una pagina scrivibile e pivotta l’esecuzione su sys_rt_sigreturn (o l’equivalente ABI rilevante). Il kernel poi “ripristina” il contesto craftato, concedendo istantaneamente il controllo completo su tutti i registri general-purpose, rip e eflags. Sfide CTF recenti (ad es., il task Hostel in n00bzCTF 2023) mostrano come le catene SROP invocano prima mprotect per trasformare lo stack in RWX, poi riutilizzano lo stesso stack per lo shellcode, bypassando efficacemente NX anche quando è disponibile solo un singolo gadget syscall; ret. Check the dedicated SROP page per altri trucchi specifici per architettura.

Ret2mprotect / ret2syscall per modificare i permessi

Se puoi chiamare mprotect, pkey_mprotect, o anche dlopen, puoi legittimamente richiedere una mappatura eseguibile prima di eseguire lo shellcode. Un piccolo scheletro pwntools potrebbe essere:

from pwn import *
elf = ELF("./vuln")
rop = ROP(elf)
rop.mprotect(elf.bss(), 0x1000, 7)
payload = flat({offset: rop.chain(), offset+len(rop.chain()): asm(shellcraft.sh())})

La stessa idea si applica alle catene ret2syscall che impostano rax=__NR_mprotect, puntano rdi a una pagina mmap/.bss, memorizzano la lunghezza desiderata in rsi e impostano rdx=7 (PROT_RWX). Una volta che esiste una regione RWX, l’esecuzione può saltare in sicurezza nei byte controllati dall’attaccante.

Primitive RWX da motori JIT e kernel

Motori JIT, interpreti, driver GPU e sottosistemi del kernel che emettono codice dinamicamente sono un modo comune per riottenere memoria eseguibile anche sotto politiche NX severe. La vulnerabilità del kernel Linux del 2024 CVE-2024-42067 ha mostrato che errori in set_memory_rox() lasciavano le pagine eBPF JIT scrivibili e eseguibili, permettendo agli attaccanti di spruzzare gadget o interi blob di shellcode all’interno del kernel nonostante le aspettative NX/W^X. Exploit che ottengono il controllo di un compilatore JIT (BPF, JavaScript, Lua, ecc.) possono quindi predisporre il payload perché risieda in quegli spazi RWX e necessitano solo di un singolo sovrascrittura di un puntatore a funzione per saltarci dentro.

Non-return code reuse (JOP/COP)

Se le istruzioni ret sono rinforzate (per es., CET/IBT) o il binario manca di ret gadget sufficientemente espressivi, passare a Jump-Oriented Programming (JOP) o Call-Oriented Programming (COP). Queste tecniche costruiscono dispatcher che usano sequenze jmp [reg] o call [reg] presenti nel binario o nelle librerie caricate. Continuano a rispettare NX perché riutilizzano codice eseguibile esistente, ma aggirano mitigazioni che controllano specificamente grandi catene di istruzioni ret.

ROP & JOP

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks