Pular para o conteúdo principal

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)

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_hook removidos), 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