Resumo de ataques por versão da glibc
Em ataques à stack é mais fácil identificar o que pode ser feito, pois basta usar pwndbg ./file e sabemos o que é ou não possível. Essas informações são fáceis de obter pois as proteções à stack estão no nível de processador (Como NX, apenas tira a permissão de escrita na Stack, e Relro também tem o mesmo conceito). Já ataques contra a heap não são tratados a nível de processador, mas são implementações na glibc. Se entendermos o que cada versão da glibc carrega, podemos guiar melhor o ataque a ser feito.
Para identificar a versão da libc de um binário:
ldd ./binario | grep libc
/lib/x86_64-linux-gnu/libc.so.6 --version
strings libc.so.6 | grep "GNU C Library"
Heap Overflow
- Todas as versões: O conceito básico de overflow continua válido, mas mitigações modernas dificultam a exploração
- glibc ≥ 2.3.4: Metadata Integrity Checks. Overflow precisa manter consistência dos dados (size, prev_size, flags)
Use After Free (UAF)
- Todas as versões - Vulnerabilidade de lógica, não da implementação do heap
- Exploração facilitada em versões mais antigas sem safe-linking
Double Free
- glibc < 2.26: Sem proteções significativas
- glibc 2.26-2.31: Double-free checks na fastbin
- glibc ≥ 2.32: Safe-linking dificulta (mas não impede completamente)
Unlink Attack
- glibc < 2.3.4: Unlink clássico sem verificações
- glibc ≥ 2.3.4: Requer bypass das verificações (P->fd->bk == P && P->bk->fd == P)
- glibc ≥ 2.26: Tcache introduzida, unlink menos relevante para chunks pequenos
- Prático até ~2.31: Após isso, outras técnicas são preferíveis
Tcache Poisoning
- glibc < 2.26: Tcache não existe
- glibc 2.26-2.31: Extremamente fácil (sem checks)
- glibc ≥ 2.32: Safe-linking XOR no fd pointer (ainda explorável com leak)
Libc Leak via Tcache
- glibc ≥ 2.26: Possível quando tcache está cheia (chunks vão para unsorted bin)
- Técnica válida em todas as versões com tcache
House of Force (Malloc Maleficarum)
- glibc < 2.29: Sem proteções
- glibc ≥ 2.29: Top Chunk Integrity Check
- glibc ≥ 2.32: Safe-linking, dificulta obter leaks necessários.
House of Spirit
- glibc < 2.32: Relativamente fácil
- glibc ≥ 2.32: Safe-linking adiciona complexidade
House of Lore
- glibc < 2.26: Viável em small bins
- glibc ≥ 2.26: Tcache interfere, precisa preencher tcache primeiro
House of Einherjar
- glibc < 2.26: Viável
- glibc ≥ 2.26: Mais difícil devido a tcache e checks
Marcos Importantes de Mitigação
- glibc 2.3.4 (2005): Unlink hardening, Metadata Integrity Checks
- glibc 2.26 (2017): Introdução da tcache (mudança massiva), Double-free checks na fastbin
- glibc 2.27 (2018): Tcache double-free check, Tcache size checks
- glibc 2.29 (2018): Tcache key (mitigação de double-free aprimorada - adicionou campo key nos chunks)
- glibc 2.29 (2019): Top Chunk Integrity Check
- glibc 2.32 (2020): Safe-linking (XOR encoding em fd pointers)
- glibc 2.34 (2021): Remoção de malloc hooks (
__malloc_hook,__free_hook,__realloc_hookremovidos), mudanças estruturais internas.
Resumo Prático
Versões antigas (< 2.26): Praticamente todos os ataques clássicos funcionam
Versões médias (2.26-2.31): Tcache poisoning lidera, ataques clássicos requerem adaptação
Versões modernas (≥ 2.32): Safe-linking requer leaks de heap, mas exploits ainda são possíveis