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

Sfioramento di un byte in eccesso

{% hint style="success" %} Impara e pratica l'Hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking su GCP: HackTricks Training GCP Red Team Expert (GRTE)

Sostieni HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.

{% endhint %}

Informazioni di base

Avere solo accesso a un overflow di 1 byte consente a un attaccante di modificare il campo size del chunk successivo. Ciò consente di manipolare quali chunk vengono effettivamente liberati, generando potenzialmente un chunk che contiene un altro chunk legittimo. L'exploit è simile al double free o al sovrapporsi dei chunk.

Ci sono 2 tipi di vulnerabilità off by one:

• Byte arbitrario: Questo tipo consente di sovrascrivere quel byte con qualsiasi valore
• Byte nullo (off-by-null): Questo tipo consente di sovrascrivere quel byte solo con 0x00
• Un esempio comune di questa vulnerabilità può essere visto nel seguente codice dove il comportamento di strlen e strcpy è inconsistente, il che consente di impostare un byte 0x00 all'inizio del chunk successivo.
• Questo può essere sfruttato con il House of Einherjar.
• Se si utilizza Tcache, questo può essere sfruttato per una situazione di double free.

Off-by-null

```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; } ```

Tra altri controlli, ora ogni volta che un chunk viene liberato, la dimensione precedente viene confrontata con la dimensione configurata nel chunk dei metadati, rendendo questo attacco piuttosto complesso dalla versione 2.28.

Esempio di codice:

• https://github.com/DhavalKapil/heap-exploitation/blob/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/shrinking_free_chunks.c
• Questo attacco non funziona più a causa dell'uso di Tcaches.
• Inoltre, se si cerca di abusarne utilizzando chunk più grandi (così che i tcaches non siano coinvolti), si otterrà l'errore: malloc(): invalid next size (unsorted)

Obiettivo

• Fare in modo che un chunk sia contenuto all'interno di un altro chunk in modo che l'accesso in scrittura su quel secondo chunk permetta di sovrascrivere quello contenuto

Requisiti

• Overflow di uno a sinistra per modificare le informazioni sui metadati della dimensione

Attacco generale off-by-one

• Allocare tre chunk A, B e C (diciamo di dimensioni 0x20), e un altro per evitare la consolidazione con il chunk superiore.
• Liberare C (inserito nella lista di chunk liberi Tcache di 0x20).
• Utilizzare il chunk A per fare overflow su B. Abusare dell'off-by-one per modificare il campo size di B da 0x21 a 0x41.
• Ora abbiamo B che contiene il chunk libero C
• Liberare B e allocare un chunk di 0x40 (verrà posizionato qui di nuovo)
• Possiamo modificare il puntatore fd da C, che è ancora libero (Tcache poisoning)

Attacco off-by-null

• Vengono riservati 3 chunk di memoria (a, b, c) uno dopo l'altro. Poi quello centrale viene liberato. Il primo contiene una vulnerabilità di overflow di uno a sinistra e l'attaccante ne abusa con un 0x00 (se il byte precedente fosse 0x10 farebbe sì che il chunk centrale indichi che è più piccolo di 0x10 di quanto non sia realmente).
• Poi, vengono allocati altri 2 chunk più piccoli nel chunk liberato al centro (b), tuttavia, poiché b + b->size non aggiorna mai il chunk c perché l'indirizzo puntato è più piccolo di quanto dovrebbe.
• Poi, vengono liberati b1 e c. Poiché c - c->prev_size punta ancora a b (ora b1), entrambi vengono consolidati in un unico chunk. Tuttavia, b2 è ancora all'interno tra b1 e c.
• Infine, viene eseguito un nuovo malloc che reclama questa area di memoria che in realtà conterrà b2, consentendo al proprietario del nuovo malloc di controllare il contenuto di b2.

Questa immagine spiega perfettamente l'attacco:

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

Altri Esempi e Riferimenti

• https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks
• Bon-nie-appetit. HTB Cyber Apocalypse CTF 2022
• Off-by-one a causa di strlen che considera il campo size del chunk successivo.
• Viene utilizzato Tcache, quindi funzionano gli attacchi generici off-by-one per ottenere un primitivo di scrittura arbitraria con Tcache poisoning.
• Asis CTF 2016 b00ks
• È possibile abusare di un off-by-one per ottenere un leak di un indirizzo dalla heap perché il byte 0x00 alla fine di una stringa viene sovrascritto dal campo successivo.
• La scrittura arbitraria viene ottenuta abusando dell'off-by-one write per far puntare il puntatore in un altro posto dove verrà costruita una struttura falsa con puntatori falsi. Quindi, è possibile seguire il puntatore di questa struttura per ottenere una scrittura arbitraria.
• L'indirizzo della libc viene leakato perché se la heap viene estesa utilizzando mmap, la memoria allocata da mmap ha un offset fisso dalla libc.
• Infine, la scrittura arbitraria viene abusata per scrivere nell'indirizzo di __free_hook con un one gadget.
• plaidctf 2015 plaiddb
• C'è una vulnerabilità NULL off-by-one nella funzione getline che legge le righe di input dell'utente. Questa funzione viene utilizzata per leggere la "chiave" del contenuto e non il contenuto.
• Condividi trucchi di hacking inviando PR ai repository HackTricks e HackTricks Cloud su GitHub.

{% endhint %}