hacktricks/binary-exploitation/libc-heap/off-by-one-overflow.md

# Off by one overflow

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}

## Basic Information

Ter apenas acesso a um overflow de 1B permite que um atacante modifique o campo `size` do próximo chunk. Isso permite manipular quais chunks são realmente liberados, potencialmente gerando um chunk que contém outro chunk legítimo. A exploração é semelhante a [double free](double-free.md) ou chunks sobrepostos.

Existem 2 tipos de vulnerabilidades off by one:

* Byte arbitrário: Este tipo permite sobrescrever esse byte com qualquer valor
* Byte nulo (off-by-null): Este tipo permite sobrescrever esse byte apenas com 0x00
* Um exemplo comum dessa vulnerabilidade pode ser visto no seguinte código onde o comportamento de `strlen` e `strcpy` é inconsistente, o que permite definir um byte 0x00 no início do próximo chunk.
* Isso pode ser explorado com a [House of Einherjar](house-of-einherjar.md).
* Se usando Tcache, isso pode ser aproveitado para uma situação de [double free](double-free.md).

<details>

<summary>Off-by-null</summary>
```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;
}
```
</details>

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 os tcaches não estejam envolvidos), você receberá o erro: `malloc(): invalid next size (unsorted)`

### Objetivo

* Fazer um chunk ser contido dentro de outro chunk, de modo que o acesso de escrita sobre esse segundo chunk permita sobrescrever o contido.

### Requisitos

* Off by one overflow para modificar as informações de metadados de tamanho.

### Ataque geral off-by-one

* Alocar três chunks `A`, `B` e `C` (digamos tamanhos 0x20), e outro para evitar a consolidação com o top-chunk.
* Liberar `C` (inserido na lista de chunks livres do Tcache de 0x20).
* Usar o chunk `A` para transbordar sobre `B`. Abusar do off-by-one para modificar o campo `size` de `B` de 0x21 para 0x41.
* Agora temos `B` contendo o chunk livre `C`.
* Liberar `B` e alocar um chunk de 0x40 (ele será colocado aqui novamente).
* Podemos modificar o ponteiro `fd` de `C`, que ainda está livre (envenenamento do Tcache).

### Ataque off-by-null

* 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 off by one e o atacante a abusa com um 0x00 (se o byte anterior fosse 0x10, isso faria o chunk do meio indicar que é 0x10 menor do que realmente é).
* Em seguida, mais 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.
* Então, b1 e c são liberados. Como `c - c->prev_size` ainda aponta para b (b1 agora), ambos são consolidados em um chunk. No entanto, b2 ainda está entre b1 e c.
* Finalmente, um novo malloc é realizado reclamando esta área de memória que na verdade vai conter b2, permitindo que o proprietário do novo malloc controle o conteúdo de b2.

Esta imagem explica perfeitamente o ataque:

<figure><img src="../../.gitbook/assets/image (1247).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks">https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks</a></p></figcaption></figure>

## Outros Exemplos & Referências

* [**https://heap-exploitation.dhavalkapil.com/attacks/shrinking\_free\_chunks**](https://heap-exploitation.dhavalkapil.com/attacks/shrinking\_free\_chunks)
* [**Bon-nie-appetit. HTB Cyber Apocalypse CTF 2022**](https://7rocky.github.io/en/ctf/htb-challenges/pwn/bon-nie-appetit/)
* Off-by-one devido ao `strlen` considerar o campo `size` do próximo chunk.
* Tcache está sendo usado, então um ataque geral off-by-one funciona para obter uma primitiva de escrita arbitrária com envenenamento do Tcache.
* [**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 off by one 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 da escrita off by one 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 em relação à libc.
* Finalmente, 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)
* Há uma vulnerabilidade de off by one NULL 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 top chunk.
* Então, 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 ]
```
* Então, abusando do chunk3 (0x1f8), o off-by-one nulo é abusado escrevendo o prev\_size para `0x4e0`.
* Note 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 ]
```
* Então, `0x200` bytes são alocados 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, aloca outro chunk com 0x58 "a"s (sobrescrevendo o chunk2 e alcançando o chunk5) e modifica o `fd` do chunk de fast bin do chunk5 apontando para `__malloc_hook`.
* Em seguida, um chunk de 0x68 é alocado para que o chunk de fast bin falso em `__malloc_hook` seja o próximo chunk de fast bin.
* Finalmente, um novo chunk de fast bin de 0x68 é alocado e `__malloc_hook` é sobrescrito com um endereço de `one_gadget`.

{% hint style="success" %}
Aprenda e pratique AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Aprenda e pratique GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-nos no** **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.

</details>
{% endhint %}