Impara e pratica l'Hacking su AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Impara e pratica l'Hacking su GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
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](double-free.md) o al sovrapporsi dei chunk.
* 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](house-of-einherjar.md).
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.
* 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
* 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.
* È 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.
* 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**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) su GitHub.