Estouro de heap.

Um estouro de heap grava além do final de um buffer alocado no heap, destruindo chunks adjacentes ou os metadados de controle gerenciados por malloc/free, jemalloc, mimalloc ou outros alocadores. Diferentemente dos estouros de pilha, não há um endereço de retorno a ser sequestrado diretamente; em vez disso, os atacantes corrompem dados nos quais o programa confiará mais tarde — o ponteiro de função de um objeto adjacente, um ponteiro de vtable de C++, o bloco de controle de um smart pointer ou os elos da lista de livres do alocador usados durante o free() (a clássica primitiva de "unlink").

Como o layout do heap não é determinístico, a exploração depende do heap grooming / feng shui: realizar alocações e liberações controladas para que um alvo útil caia imediatamente após o buffer vulnerável. Um caso real canônico é o GHOST (CVE-2015-0235), um estouro de heap na função __nss_hostname_digits_dots() da glibc, alcançável por meio de gethostbyname(); a Qualys demonstrou em 2015 a execução remota de código completa contra o servidor de e-mail Exim, e a falha existia silenciosamente desde a glibc 2.2. O CVE-2018-4407 mostrou a mesma classe no kernel XNU da Apple, acionável remotamente por um único pacote TCP forjado.

flowchart TD
  A[Alocar objeto vítima + buffer vulnerável de forma adjacente] --> B[O heap grooming posiciona o alvo após o buffer]
  B --> C[O estouro grava além do final do buffer]
  C --> D{Alvo corrompido}
  D -->|Metadados do alocador| E[free unlink -> escrita arbitrária]
  D -->|Ponteiro de função / vtable| F[Redirecionar o fluxo de controle]
  E --> G[Execução de código]
  F --> G

As defesas combinam o endurecimento do alocador (verificações de integridade de metadados, unlink seguro, isolamento de chunks, páginas de guarda) com ASLR, CFI, sandboxing e a migração para linguagens seguras em memória, como o Rust. Os estouros de heap continuam centrais na exploração de navegadores, kernels e analisadores de documentos, e figuram fortemente nas cadeias vencedoras do Pwn2Own.