Sfioramento overflow

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
Ottieni il merchandising ufficiale di PEASS & HackTricks
Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi
Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud repos di github.

Informazioni di base

Avere solo accesso a un overflow di 1B consente a un attaccante di modificare le informazioni sui metadati delle dimensioni precedenti, consentendo di manomettere quali chunk vengono effettivamente liberati, generando infine un chunk che contiene un altro chunk legittimo.

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 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 consenta di sovrascrivere quello contenuto

Requisiti

Sfioramento overflow di uno per modificare le informazioni sui metadati delle dimensioni precedenti

Attacco

Vengono riservati 3 chunk di memoria (a, b, c) uno dopo l'altro. Quindi il chunk centrale viene liberato. Il primo contiene una vulnerabilità di sfioramento di uno e l'attaccante la sfrutta 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).
Quindi, vengono allocati altri 2 chunk più piccoli nel chunk centrale liberato (b), tuttavia, poiché b + b->size non aggiorna mai il chunk c perché l'indirizzo puntato è più piccolo di quanto dovrebbe essere.
Quindi, b1 e c vengono liberati. 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

Riferimenti

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