# Estouro por um byte
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
## Informações Básicas Ter apenas acesso a um estouro de 1 byte permite a um atacante modificar o bit `pre_in_use` do próximo chunk e, como o chunk atual não estará em uso, o final do chunk se torna a informação de metadados do tamanho do chunk anterior.\ Isso permite manipular quais chunks estão realmente liberados, potencialmente gerando um chunk que contém outro chunk legítimo. Existem 2 tipos de vulnerabilidades de estouro por um byte: * Byte arbitrário: Este tipo permite sobrescrever esse byte com qualquer valor * Null off by one: Este tipo permite sobrescrever esse byte apenas com 0x00 * Um exemplo comum dessa vulnerabilidade pode ser visto no código a seguir, onde o comportamento de strlen e strcpy é inconsistente, o que permite definir um byte 0x00 no início do próximo chunk.
Null off by one ```c // From https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/off_by_one/ int main(void) { char buffer[40]=""; void *chunk1; chunk1 = malloc(24); puts("Get Input"); gets(buffer); if(strlen(buffer)==24) { strcpy(chunk1,buffer); } return 0; } ```
Entre outras verificações, agora sempre que um chunk é liberado, o tamanho anterior é comparado com o tamanho configurado nos metadados do chunk, tornando esse ataque bastante complexo a partir da versão 2.28. ### Exemplo de Código: * [https://github.com/DhavalKapil/heap-exploitation/blob/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/shrinking\_free\_chunks.c](https://github.com/DhavalKapil/heap-exploitation/blob/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/shrinking\_free\_chunks.c) * Este ataque não está mais funcionando devido ao uso de Tcaches. * Além disso, se você tentar abusar dele usando chunks maiores (para que as tcaches não estejam envolvidas), você receberá o erro: `malloc(): invalid next size (unsorted)` ### Objetivo * Fazer um chunk estar contido dentro de outro chunk, de modo que o acesso de escrita sobre esse segundo chunk permita sobrescrever o contido ### Requisitos * Estouro de um byte para modificar as informações de metadados do tamanho anterior ### Ataque * 3 chunks de memória (a, b, c) são reservados um após o outro. Em seguida, o do meio é liberado. O primeiro contém uma vulnerabilidade de estouro de um byte e o atacante a abusa com um 0x00 (se o byte anterior fosse 0x10, faria com que o chunk do meio indicasse que é 0x10 menor do que realmente é). * Em seguida, 2 chunks menores são alocados no chunk liberado do meio (b), no entanto, como `b + b->size` nunca atualiza o chunk c porque o endereço apontado é menor do que deveria ser. * Em seguida, b1 e c são liberados. Como `c - c->prev_size` ainda aponta para b (agora b1), ambos são consolidados em um único chunk. No entanto, b2 ainda está dentro, entre b1 e c. * Por fim, é feito um novo malloc para recuperar essa área de memória que na verdade vai conter b2, permitindo ao proprietário do novo malloc controlar o conteúdo de b2. Esta imagem explica perfeitamente o ataque:

https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks

## Outros Exemplos e Referências * [**https://heap-exploitation.dhavalkapil.com/attacks/shrinking\_free\_chunks**](https://heap-exploitation.dhavalkapil.com/attacks/shrinking\_free\_chunks) * [**Asis CTF 2016 b00ks**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/off\_by\_one/#1-asis-ctf-2016-b00ks) * É possível abusar de um estouro de um byte para vazar um endereço do heap porque o byte 0x00 do final de uma string está sendo sobrescrito pelo próximo campo. * A escrita arbitrária é obtida abusando do estouro de um byte para fazer o ponteiro apontar para outro lugar onde uma estrutura falsa com ponteiros falsos será construída. Em seguida, é possível seguir o ponteiro desta estrutura para obter escrita arbitrária. * O endereço da libc é vazado porque se o heap for estendido usando mmap, a memória alocada por mmap tem um deslocamento fixo da libc. * Por fim, a escrita arbitrária é abusada para escrever no endereço de \_\_free\_hook com um one gadget. * [**plaidctf 2015 plaiddb**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/off\_by\_one/#instance-2-plaidctf-2015-plaiddb) * Existe uma vulnerabilidade de estouro de um byte nulo na função `getline` que lê linhas de entrada do usuário. Esta função é usada para ler a "chave" do conteúdo e não o conteúdo. * No writeup, 5 chunks iniciais são criados: * chunk1 (0x200) * chunk2 (0x50) * chunk5 (0x68) * chunk3 (0x1f8) * chunk4 (0xf0) * chunk defense (0x400) para evitar a consolidação com o chunk superior * Em seguida, os chunks 1, 5 e 3 são liberados, então: * ```python [ 0x200 Chunk 1 (free) ] [ 0x50 Chunk 2 ] [ 0x68 Chunk 5 (free) ] [ 0x1f8 Chunk 3 (free) ] [ 0xf0 Chunk 4 ] [ 0x400 Chunk defense ] ``` * Em seguida, abusando do chunk3 (0x1f8), o estouro de um byte nulo é abusado escrevendo o prev\_size para `0x4e0`. * Observe como os tamanhos dos chunks inicialmente alocados 1, 2, 5 e 3 mais os cabeçalhos de 4 desses chunks somam `0x4e0`: `hex(0x1f8 + 0x10 + 0x68 + 0x10 + 0x50 + 0x10 + 0x200) = 0x4e0` * Em seguida, o chunk 4 é liberado, gerando um chunk que consome todos os chunks até o início: * ```python [ 0x4e0 Chunk 1-2-5-3 (free) ] [ 0xf0 Chunk 4 (corrupted) ] [ 0x400 Chunk defense ] ``` * ```python [ 0x200 Chunk 1 (free) ] [ 0x50 Chunk 2 ] [ 0x68 Chunk 5 (free) ] [ 0x1f8 Chunk 3 (free) ] [ 0xf0 Chunk 4 ] [ 0x400 Chunk defense ] ``` * Em seguida, são alocados `0x200` bytes preenchendo o chunk original 1 * E mais 0x200 bytes são alocados e o chunk2 é destruído e, portanto, não há vazamento e isso não funciona? Talvez isso não devesse ser feito * Em seguida, é alocado um outro chunk com 0x58 "a"s (sobrescrevendo o chunk2 e alcançando o chunk5) e modifica o `fd` do chunk fast bin de chunk5 apontando para `__malloc_hook` * Em seguida, é alocado um chunk de 0x68 para que o chunk fast bin falso em `__malloc_hook` seja o seguinte * Por fim, um novo chunk fast bin de 0x68 é alocado e `__malloc_hook` é sobrescrito com um endereço `one_gadget`
Aprenda hacking AWS do zero ao hero com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).