mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 04:33:28 +00:00
Translated ['binary-exploitation/heap/bins-and-memory-allocations.md', '
This commit is contained in:
Translator
parent
3855c6c4b6
commit
4038e77974
5 changed files with 165 additions and 87 deletions
|
|
@ -731,6 +731,7 @@
|
|||
* [Use After Free](binary-exploitation/heap/use-after-free/README.md)
|
||||
* [First Fit](binary-exploitation/heap/use-after-free/first-fit.md)
|
||||
* [Double Free](binary-exploitation/heap/double-free.md)
|
||||
* [Overwriting a freed chunk](binary-exploitation/heap/overwriting-a-freed-chunk.md)
|
||||
* [Heap Overflow](binary-exploitation/heap/heap-overflow.md)
|
||||
* [Unlink Attack](binary-exploitation/heap/unlink-attack.md)
|
||||
* [Fast Bin Attack](binary-exploitation/heap/fast-bin-attack.md)
|
||||
|
|
|
|||
|
|
@ -2,11 +2,11 @@
|
|||
|
||||
<details>
|
||||
|
||||
<summary><strong>Impara l'hacking AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Impara l'hacking su AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* **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)**.**
|
||||
|
|
@ -18,18 +18,18 @@ Altri modi per supportare HackTricks:
|
|||
|
||||
Per migliorare l'efficienza su come i chunk sono memorizzati, ogni chunk non è solo in una lista concatenata, ma ci sono diversi tipi. Questi sono i bins e ci sono 5 tipi di bins: [62](https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l1407) small bins, 63 large bins, 1 unsorted bin, 10 fast bins e 64 tcache bins per thread.
|
||||
|
||||
L'indirizzo iniziale di ogni bin non ordinato, small e large è all'interno dello stesso array. L'indice 0 non è utilizzato, 1 è il bin non ordinato, i bin da 2 a 64 sono i small bins e i bin da 65 a 127 sono i large bins.
|
||||
L'indirizzo iniziale di ogni bin non ordinato, small e large è all'interno dello stesso array. L'indice 0 non è utilizzato, 1 è il bin non ordinato, i bins da 2 a 64 sono i small bins e i bins da 65 a 127 sono i large bins.
|
||||
|
||||
### Bins Tcache (Cache Per-Thread)
|
||||
|
||||
Anche se i thread cercano di avere il proprio heap (vedi [Arenas](bins-and-memory-allocations.md#arenas) e [Subheaps](bins-and-memory-allocations.md#subheaps)), c'è la possibilità che un processo con molti thread (come un server web) **finirà per condividere l'heap con altri thread**. In questo caso, la soluzione principale è l'uso di **lock**, che potrebbero **rallentare significativamente i thread**.
|
||||
|
||||
Pertanto, un tcache è simile a un bin veloce per thread nel senso che è una **lista concatenata singola** che non unisce i chunk. Ogni thread ha **64 tcache bins collegati singolarmente**. Ogni bin può avere un massimo di [7 chunk della stessa dimensione](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) che vanno da [24 a 1032B su sistemi a 64 bit e da 12 a 516B su sistemi a 32 bit](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
|
||||
Pertanto, una tcache è simile a un bin veloce per thread nel senso che è una **lista concatenata singola** che non unisce i chunk. Ogni thread ha **64 tcache bins collegati singolarmente**. Ogni bin può avere un massimo di [7 chunk della stessa dimensione](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) che vanno da [24 a 1032B nei sistemi a 64 bit e da 12 a 516B nei sistemi a 32 bit](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
|
||||
|
||||
Quando un thread libera un chunk, se non è troppo grande per essere allocato nel tcache e il rispettivo bin tcache **non è pieno** (già 7 chunk), **verrà allocato lì**. Se non può andare nel tcache, dovrà aspettare che il lock dell'heap sia in grado di eseguire l'operazione di liberazione globalmente.
|
||||
Quando un thread libera un chunk, se non è troppo grande da essere allocato nella tcache e il rispettivo bin tcache **non è pieno** (già 7 chunk), **verrà allocato lì**. Se non può andare nella tcache, dovrà aspettare che il lock dell'heap sia in grado di eseguire l'operazione di liberazione globalmente.
|
||||
|
||||
Quando un **chunk viene allocato**, se c'è un chunk libero della dimensione necessaria nel **Tcache lo utilizzerà**, altrimenti dovrà aspettare che il lock dell'heap sia in grado di trovarne uno nei bin globali o crearne uno nuovo.\
|
||||
C'è anche un'ottimizzazione, in questo caso, mentre ha il lock dell'heap, il thread **riempirà il suo Tcache con chunk dell'heap (7) della dimensione richiesta**, quindi se ne ha bisogno di più, li troverà nel Tcache.
|
||||
Quando un **chunk viene allocato**, se c'è un chunk libero della dimensione necessaria nella **tcache lo utilizzerà**, altrimenti dovrà aspettare che il lock dell'heap sia in grado di trovarne uno nei bin globali o crearne uno nuovo.\
|
||||
C'è anche un'ottimizzazione, in questo caso, mentre ha il lock dell'heap, il thread **riempirà la sua tcache con chunk dell'heap (7) della dimensione richiesta**, quindi se ne ha bisogno di più, li troverà nella tcache.
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ free(chunk);
|
|||
return 0;
|
||||
}
|
||||
```
|
||||
Compilalo e debuggalo con un breakpoint nell'opcode ret dalla funzione main. Poi con gef puoi vedere il bin tcache in uso:
|
||||
Compilalo e debuggalo con un breakpoint nell'opcode ret dalla funzione main. poi con gef puoi vedere il tcache bin in uso:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
|
|
@ -56,11 +56,7 @@ Tcachebins[idx=0, size=0x20, count=1] ← Chunk(addr=0xaaaaaaac12a0, size=0x20,
|
|||
```
|
||||
#### Strutture e Funzioni Tcache
|
||||
|
||||
Nel codice seguente è possibile vedere i **max bins** e i **chunks per index**, la struct **`tcache_entry`** creata per evitare doppie liberazioni e **`tcache_perthread_struct`**, una struct che ogni thread utilizza per memorizzare gli indirizzi di ogni indice del bin.
|
||||
|
||||
<details>
|
||||
|
||||
<summary><code>tcache_entry</code> e <code>tcache_perthread_struct</code></summary>
|
||||
Nel codice seguente è possibile vedere i **max bins** e i **chunks per indice**, la struttura **`tcache_entry`** creata per evitare doppie liberazioni e **`tcache_perthread_struct`**, una struttura che ogni thread utilizza per memorizzare gli indirizzi di ogni indice del bin.
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c
|
||||
|
||||
|
|
@ -116,7 +112,7 @@ La funzione `__tcache_init` è la funzione che crea e alloca lo spazio per l'ogg
|
|||
|
||||
<details>
|
||||
|
||||
<summary>codice tcache_init</summary>
|
||||
<summary>codice di inizializzazione della tcache</summary>
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L3241C1-L3274C2
|
||||
|
||||
|
|
@ -157,21 +153,25 @@ memset (tcache, 0, sizeof (tcache_perthread_struct));
|
|||
```
|
||||
</details>
|
||||
|
||||
### Bins veloci
|
||||
#### Indici Tcache
|
||||
|
||||
Le fast bins sono progettati per **accelerare l'allocazione di memoria per piccoli chunk** mantenendo i chunk recentemente liberati in una struttura di accesso rapido. Questi bins utilizzano un approccio Last-In, First-Out (LIFO), il che significa che il **chunk liberato più di recente è il primo** ad essere riutilizzato quando c'è una nuova richiesta di allocazione. Questo comportamento è vantaggioso per la velocità, poiché è più veloce inserire e rimuovere dalla cima di uno stack (LIFO) rispetto a una coda (FIFO).
|
||||
Il tcache ha diversi bin a seconda della dimensione e i puntatori iniziali al **primo chunk di ciascun indice e la quantità di chunk per indice sono situati all'interno di un chunk**. Ciò significa che individuando il chunk con queste informazioni (di solito il primo), è possibile trovare tutti i punti iniziali del tcache e la quantità di chunk del Tcache.
|
||||
|
||||
Inoltre, **i fast bins utilizzano liste collegate singolarmente**, non doppie, il che migliora ulteriormente la velocità. Poiché i chunk nei fast bins non vengono uniti ai vicini, non c'è bisogno di una struttura complessa che permetta la rimozione dal mezzo. Una lista collegata singolarmente è più semplice e veloce per queste operazioni.
|
||||
### Fast bins
|
||||
|
||||
I fast bins sono progettati per **accelerare l'allocazione di memoria per piccoli chunk** mantenendo i chunk liberati di recente in una struttura di accesso rapido. Questi bin utilizzano un approccio Last-In, First-Out (LIFO), il che significa che il **chunk liberato più di recente è il primo** ad essere riutilizzato quando c'è una nuova richiesta di allocazione. Questo comportamento è vantaggioso per la velocità, poiché è più veloce inserire e rimuovere dalla cima di uno stack (LIFO) rispetto a una coda (FIFO).
|
||||
|
||||
Inoltre, **i fast bins utilizzano liste collegate singolarmente**, non doppie, il che migliora ulteriormente la velocità. Poiché i chunk nei fast bins non vengono uniti con i vicini, non c'è bisogno di una struttura complessa che consenta la rimozione dal mezzo. Una lista collegata singolarmente è più semplice e veloce per queste operazioni.
|
||||
|
||||
Fondamentalmente, ciò che accade qui è che l'intestazione (il puntatore al primo chunk da controllare) punta sempre all'ultimo chunk liberato di quella dimensione. Quindi:
|
||||
|
||||
* Quando viene allocato un nuovo chunk di quella dimensione, l'intestazione punta a un chunk libero da utilizzare. Poiché questo chunk libero punta al successivo da utilizzare, questo indirizzo viene memorizzato nell'intestazione in modo che la prossima allocazione sappia dove ottenere un chunk disponibile
|
||||
* Quando un chunk viene liberato, il chunk libero salverà l'indirizzo al chunk disponibile corrente e l'indirizzo a questo nuovo chunk liberato verrà messo nell'intestazione
|
||||
* Quando un chunk viene liberato, il chunk libero salverà l'indirizzo al chunk disponibile corrente e l'indirizzo a questo nuovo chunk liberato verrà inserito nell'intestazione
|
||||
|
||||
La dimensione massima di una lista collegata è `0x80` e sono organizzate in modo che un chunk di dimensione `0x20-0x2f` sarà nell'indice `0`, un chunk di dimensione `0x30-0x3f` sarebbe in `idx` `1`...
|
||||
La dimensione massima di una lista collegata è `0x80` e sono organizzate in modo che un chunk di dimensione `0x20-0x2f` sarà nell'indice `0`, un chunk di dimensione `0x30-0x3f` sarà in `idx` `1`...
|
||||
|
||||
{% hint style="danger" %}
|
||||
I chunk nei fast bins non vengono impostati come disponibili, quindi vengono mantenuti come chunk fast bin per un po' di tempo invece di poter essere uniti ad altri chunk liberi circostanti.
|
||||
I chunk nei fast bins non vengono impostati come disponibili, quindi vengono mantenuti come chunk fast bin per un certo periodo anziché poter essere uniti con altri chunk liberi circostanti.
|
||||
{% endhint %}
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
|
||||
|
|
@ -236,9 +236,9 @@ free(chunks[i]);
|
|||
return 0;
|
||||
}
|
||||
```
|
||||
Nota come allocare e liberare 8 chunk dello stesso size in modo che riempiano il tcache e l'ottavo sia memorizzato nel fast chunk.
|
||||
Nota come allocare e liberare 8 chunk dello stesso size in modo che riempiano la tcache e l'ottavo sia memorizzato nel fast chunk.
|
||||
|
||||
Compilalo e debuggalo con un breakpoint nell'opcode ret dalla funzione principale. Poi con gef puoi vedere il riempimento del tcache bin e il chunk in fast bin:
|
||||
Compila e debugga con un breakpoint nell'opcode ret dalla funzione principale. Poi con gef puoi vedere il riempimento del tcache bin e il chunk in fast bin:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
|
|
@ -249,7 +249,7 @@ Fastbins[idx=1, size=0x30] 0x00
|
|||
```
|
||||
</details>
|
||||
|
||||
### Bins non ordinati
|
||||
### Bin non ordinato
|
||||
|
||||
Il bin non ordinato è una **cache** utilizzata dal gestore dell'heap per rendere più veloce l'allocazione di memoria. Ecco come funziona: quando un programma libera un chunk e se questo chunk non può essere allocato in un tcache o in un fast bin e non entra in collisione con il top chunk, il gestore dell'heap non lo mette immediatamente in un bin specifico piccolo o grande. Invece, prima cerca di **fonderlo con eventuali chunk liberi vicini** per creare un blocco più grande di memoria libera. Successivamente, posiziona questo nuovo chunk in un bin generale chiamato "bin non ordinato".
|
||||
|
||||
|
|
@ -257,7 +257,7 @@ Quando un programma **richiede memoria**, il gestore dell'heap **controlla il bi
|
|||
|
||||
Si noti che se un chunk più grande viene diviso in 2 metà e il resto è più grande di MINSIZE, verrà riposizionato nel bin non ordinato. 
|
||||
|
||||
Quindi, il bin non ordinato è un modo per velocizzare l'allocazione di memoria riutilizzando rapidamente la memoria liberata di recente e riducendo la necessità di ricerche e fusioni dispendiose in termini di tempo.
|
||||
Quindi, il bin non ordinato è un modo per velocizzare l'allocazione di memoria riutilizzando rapidamente la memoria liberata di recente e riducendo la necessità di ricerche e fusioni che richiedono tempo.
|
||||
|
||||
{% hint style="danger" %}
|
||||
Si noti che anche se i chunk sono di categorie diverse, se un chunk disponibile entra in collisione con un altro chunk disponibile (anche se appartengono originariamente a bin diversi), verranno fusi.
|
||||
|
|
@ -293,9 +293,9 @@ free(chunks[i]);
|
|||
return 0;
|
||||
}
|
||||
```
|
||||
Nota come allocare e liberare 9 chunk dello stesso size in modo che riempiano il tcache e l'ottavo venga memorizzato nell'unsorted bin perché è troppo grande per il fastbin e il nono non viene liberato in modo che il nono e l'ottavo non vengano uniti con il top chunk.
|
||||
Nota come allocare e liberare 9 chunk dello stesso size in modo che **riempiano il tcache** e l'ottavo sia memorizzato nell'unsorted bin perché è **troppo grande per il fastbin** e il nono non è liberato quindi il nono e l'ottavo **non vengono uniti con il top chunk**.
|
||||
|
||||
Compilalo e debuggalo con un breakpoint nell'opcode ret dalla funzione principale. Poi con gef puoi vedere il riempimento del tcache bin e il chunk nell'unsorted bin:
|
||||
Compilalo e debuggalo con un breakpoint nell'opcode ret dalla funzione main. Poi con gef puoi vedere il riempimento del tcache bin e il chunk nell'unsorted bin:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
|
|
@ -339,27 +339,7 @@ Ecco come viene calcolata la dimensione del bin piccolo in base all'indice del b
|
|||
((SMALLBIN_WIDTH == 16 ? (((unsigned) (sz)) >> 4) : (((unsigned) (sz)) >> 3))\
|
||||
+ SMALLBIN_CORRECTION)
|
||||
```
|
||||
```c
|
||||
void *choose_bin(size_t size) {
|
||||
if (size <= SMALL_BIN_SIZE) {
|
||||
return small_bin;
|
||||
} else {
|
||||
return large_bin;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
```c
|
||||
void *choose_bin(size_t size) {
|
||||
if (size <= SMALL_BIN_SIZE) {
|
||||
return small_bin;
|
||||
} else {
|
||||
return large_bin;
|
||||
}
|
||||
}
|
||||
```
|
||||
Funzione per scegliere tra i bin piccoli e grandi:
|
||||
```c
|
||||
#define bin_index(sz) \
|
||||
((in_smallbin_range (sz)) ? smallbin_index (sz) : largebin_index (sz))
|
||||
|
|
@ -422,20 +402,20 @@ Fastbins[idx=6, size=0x80] 0x00
|
|||
|
||||
### Bins grandi
|
||||
|
||||
A differenza dei blocchi piccoli, che gestiscono pezzi di dimensioni fisse, **ogni bin grande gestisce un intervallo di dimensioni di pezzi**. Questo è più flessibile, permettendo al sistema di gestire **varie dimensioni** senza la necessità di un bin separato per ogni dimensione.
|
||||
A differenza dei blocchi piccoli, che gestiscono pezzi di dimensioni fisse, **ogni bin grande gestisce un intervallo di dimensioni di pezzi**. Questo è più flessibile, permettendo al sistema di gestire **varie dimensioni** senza la necessità di avere un bin separato per ogni dimensione.
|
||||
|
||||
In un allocatore di memoria, i bin grandi iniziano dove finiscono i bin piccoli. Gli intervalli per i bin grandi crescono progressivamente, il che significa che il primo bin potrebbe coprire pezzi da 512 a 576 byte, mentre il successivo copre da 576 a 640 byte. Questo modello continua, con il bin più grande che contiene tutti i pezzi sopra 1MB.
|
||||
|
||||
I bin grandi sono più lenti da gestire rispetto ai bin piccoli perché devono **ordinare e cercare attraverso un elenco di dimensioni di pezzi variabili per trovare la migliore corrispondenza** per un'allocazione. Quando un pezzo viene inserito in un bin grande, deve essere ordinato, e quando la memoria viene allocata, il sistema deve trovare il pezzo giusto. Questo lavoro aggiuntivo li rende **più lenti**, ma poiché le allocazioni grandi sono meno comuni di quelle piccole, è un compromesso accettabile.
|
||||
I bin grandi sono più lenti da gestire rispetto ai bin piccoli perché devono **ordinare e cercare in una lista di dimensioni di pezzi variabili per trovare la migliore corrispondenza** per un'allocazione. Quando un pezzo viene inserito in un bin grande, deve essere ordinato, e quando la memoria viene allocata, il sistema deve trovare il pezzo giusto. Questo lavoro aggiuntivo li rende **più lenti**, ma poiché le allocazioni grandi sono meno comuni di quelle piccole, è un compromesso accettabile.
|
||||
|
||||
Ci sono:
|
||||
|
||||
* 32 bin di intervallo 64B (collidono con i bin piccoli)
|
||||
* 16 bin di intervallo 512B (collidono con i bin piccoli)
|
||||
* 8 bin di intervallo 4096B (parte collidono con i bin piccoli)
|
||||
* 8 bin di intervallo 4096B (in parte collidono con i bin piccoli)
|
||||
* 4 bin di intervallo 32768B
|
||||
* 2 bin di intervallo 262144B
|
||||
* 1 bin per dimensioni rimanenti
|
||||
* 1 bin per le dimensioni rimanenti
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -479,7 +459,7 @@ Ci sono:
|
|||
|
||||
<details>
|
||||
|
||||
<summary>Aggiungi un esempio di un grosso chunk</summary>
|
||||
<summary>Aggiungi un esempio di chunk grande</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
|
@ -547,7 +527,7 @@ the 2 preceding words to be zero during this interval as well.)
|
|||
/* Conveniently, the unsorted bin can be used as dummy top on first call */
|
||||
#define initial_top(M) (unsorted_chunks (M))
|
||||
```
|
||||
Fondamentalmente, questo è un chunk che contiene tutto l'heap attualmente disponibile. Quando viene eseguito un malloc, se non ci sono chunk liberi disponibili da utilizzare, questo top chunk ridurrà la sua dimensione fornendo lo spazio necessario.\
|
||||
Fondamentalmente, questo è un chunk che contiene tutto l'heap attualmente disponibile. Quando viene eseguito un malloc, se non c'è alcun chunk libero disponibile da utilizzare, questo top chunk ridurrà la sua dimensione fornendo lo spazio necessario.\
|
||||
Il puntatore al Top Chunk è memorizzato nella struttura `malloc_state`.
|
||||
|
||||
Inoltre, all'inizio, è possibile utilizzare lo chunk non ordinato come top chunk.
|
||||
|
|
@ -592,7 +572,7 @@ gef➤ x/8wx 0xaaaaaaac1ae0 - 16
|
|||
|
||||
### Ultimo Promemoria
|
||||
|
||||
Quando viene utilizzato malloc e un chunk viene diviso (dalla lista non collegata o dal chunk superiore ad esempio), il chunk creato dal resto del chunk diviso è chiamato Ultimo Promemoria e il suo puntatore è memorizzato nella struttura `malloc_state`.
|
||||
Quando viene utilizzato malloc e un chunk viene diviso (dalla lista non collegata o dal chunk superiore ad esempio), il chunk creato dal resto del chunk diviso viene chiamato Ultimo Promemoria e il suo puntatore è memorizzato nella struttura `malloc_state`.
|
||||
|
||||
## Flusso di Allocazione
|
||||
|
||||
|
|
@ -635,6 +615,6 @@ Altri modi per supportare HackTricks:
|
|||
* Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* **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)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di github.
|
||||
|
||||
</details>
|
||||
|
|
|
|||
47
binary-exploitation/heap/overwriting-a-freed-chunk.md
Normal file
47
binary-exploitation/heap/overwriting-a-freed-chunk.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
# Sovrascrittura di un chunk liberato
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Impara l'hacking su AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la **tua azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT**](https://opensea.io/collection/the-peass-family) esclusivi
|
||||
* **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)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di Github.
|
||||
|
||||
</details>
|
||||
|
||||
Diverse delle tecniche di sfruttamento dell'heap proposte richiedono la capacità di sovrascrivere i puntatori all'interno di chunk liberati. Lo scopo di questa pagina è riassumere le potenziali vulnerabilità che potrebbero concedere questo accesso:
|
||||
|
||||
### Semplice Use After Free
|
||||
|
||||
Se è possibile per l'attaccante **scrivere informazioni in un chunk libero**, potrebbe sfruttarlo per sovrascrivere i puntatori necessari.
|
||||
|
||||
### Doppio Free
|
||||
|
||||
Se l'attaccante può **`free` due volte lo stesso chunk** (liberare altri chunk nel mezzo potenzialmente) e far sì che sia **2 volte nello stesso bin**, sarebbe possibile per l'utente **allocare il chunk successivamente**, **scrivere i puntatori necessari** e poi **allocarlo di nuovo** attivando le azioni dell'allocazione del chunk (ad es. attacco al fast bin, attacco al tcache...)
|
||||
|
||||
### Heap Overflow
|
||||
|
||||
Potrebbe essere possibile **sovraffluire un chunk allocato con successivo un chunk liberato** e modificare alcuni header/puntatori di esso.
|
||||
|
||||
### Sovrafflusso di 1
|
||||
|
||||
In questo caso sarebbe possibile **modificare la dimensione** del chunk successivo in memoria. Un attaccante potrebbe sfruttare questo per **far sì che un chunk allocato abbia una dimensione maggiore**, quindi **`free`**arlo, facendo sì che il chunk venga **aggiunto a un bin di dimensioni diverse** (più grandi), quindi allocare la **dimensione falsa**, e l'attacco avrà accesso a un **chunk con una dimensione maggiore** di quella reale, **concedendo quindi un heap overflow** (controlla la sezione precedente).
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Impara l'hacking su AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la **tua azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT**](https://opensea.io/collection/the-peass-family) esclusivi
|
||||
* **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)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di Github.
|
||||
|
||||
</details>
|
||||
|
|
@ -2,15 +2,15 @@
|
|||
|
||||
<details>
|
||||
|
||||
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Impara l'hacking su AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Se vuoi vedere la **tua azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* **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)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e ai [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di github.
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di Github.
|
||||
|
||||
</details>
|
||||
|
||||
|
|
@ -24,6 +24,37 @@ Per ulteriori informazioni su cosa sia un bin di tcache, controlla questa pagina
|
|||
|
||||
Innanzitutto, nota che il Tcache è stato introdotto nella versione 2.26 di glibc.
|
||||
|
||||
L'attacco **Tcache** proposto nella [**pagina guyinatuxido**](https://guyinatuxedo.github.io/29-tcache/tcache\_explanation/index.html) è molto simile all'attacco fast bin dove l'obiettivo è sovrascrivere il puntatore al prossimo chunk nel bin all'interno di un chunk liberato con un indirizzo arbitrario in modo da poter successivamente **allocare quell'indirizzo specifico e sovrascrivere potenzialmente i puntatori**.
|
||||
L'attacco al **Tcache** proposto nella [**pagina guyinatuxido**](https://guyinatuxedo.github.io/29-tcache/tcache\_explanation/index.html) è molto simile all'attacco al fast bin dove l'obiettivo è sovrascrivere il puntatore al chunk successivo nel bin all'interno di un chunk liberato con un indirizzo arbitrario in modo da **allocare quell'indirizzo specifico e potenzialmente sovrascrivere i puntatori**.
|
||||
|
||||
Tuttavia, al giorno d'oggi, se esegui il codice menzionato otterrai l'errore: **`malloc(): unaligned tcache chunk detected`**. Quindi, è necessario scrivere come indirizzo nel nuovo puntatore un indirizzo allineato (o eseguire abbastanza volte il binario in modo che l'indirizzo scritto sia effettivamente allineato).
|
||||
|
||||
### Attacco agli indici di Tcache
|
||||
|
||||
Di solito è possibile trovare all'inizio dell'heap un chunk contenente la **quantità di chunk per indice** all'interno del tcache e l'indirizzo al **chunk di testa di ciascun indice di tcache**. Se per qualche motivo è possibile modificare queste informazioni, sarebbe possibile **far puntare il chunk di testa di alcuni indici a un indirizzo desiderato** (come il malloc hook) per poi allocare un chunk della dimensione dell'indice e sovrascrivere i contenuti del malloc hook in questo caso.
|
||||
|
||||
## Esempi
|
||||
|
||||
* CTF [https://guyinatuxedo.github.io/29-tcache/dcquals19\_babyheap/index.html](https://guyinatuxedo.github.io/29-tcache/dcquals19\_babyheap/index.html)
|
||||
* **Leak di informazioni sulla libc**: È possibile riempire i tcache, aggiungere un chunk nella lista non ordinata, svuotare il tcache e **ri-allocare il chunk dalla lista non ordinata** sovrascrivendo solo i primi 8B, lasciando **intatto il secondo indirizzo alla libc dal chunk in modo da poterlo leggere**.
|
||||
* **Attacco al Tcache**: Il binario è vulnerabile a un overflow di heap di 1B. Questo sarà abusato per cambiare l'**intestazione di dimensione** di un chunk allocato rendendola più grande. Quindi, questo chunk verrà **liberato**, aggiungendolo al tcache dei chunk della dimensione falsa. Poi, verrà allocato un chunk con la dimensione falsata e il chunk precedente verrà **restituito sapendo che questo chunk era effettivamente più piccolo** e ciò permette di **sovrascrivere il chunk successivo in memoria**.\
|
||||
Questo sarà abusato per **sovrascrivere il puntatore FD del chunk successivo** per farlo puntare a **`malloc_hook`**, quindi è possibile allocare 2 puntatori: prima il puntatore legittimo appena modificato e poi la seconda allocazione restituirà un chunk in **`malloc_hook`** che è possibile abusare per scrivere un **one gadget**.
|
||||
* CTF [https://guyinatuxedo.github.io/29-tcache/plaid19\_cpp/index.html](https://guyinatuxedo.github.io/29-tcache/plaid19\_cpp/index.html)
|
||||
* **Leak di informazioni sulla libc**: C'è un use after free e un double free. In questo writeup l'autore ha fatto trapelare un indirizzo della libc leggendo l'indirizzo di un chunk posizionato in un bin piccolo (come se lo stesse facendo trapelare dal bin non ordinato ma da quello piccolo)
|
||||
* **Attacco al Tcache**: Viene eseguito un Tcache tramite un **double free**. Lo stesso chunk viene liberato due volte, quindi all'interno del Tcache il chunk punterà a se stesso. Quindi, viene allocato, il suo puntatore FD viene modificato per puntare al **free hook** e quindi viene allocato di nuovo in modo che il prossimo chunk nella lista sarà nel free hook. Poi, anche questo viene allocato ed è possibile scrivere l'indirizzo di `system` qui in modo che quando un malloc contenente `"/bin/sh"` viene liberato otteniamo una shell.
|
||||
* CTF [https://guyinatuxedo.github.io/44-more\_tcache/csaw19\_popping\_caps0/index.html](https://guyinatuxedo.github.io/44-more\_tcache/csaw19\_popping\_caps0/index.html)
|
||||
* **Attacco agli indici di Tcache**: È possibile allocare e liberare un chunk di una dimensione tale che quando memorizzato nelle informazioni del tcache genererà una **posizione con il valore 0x100** (perché il byte che indica quanti chunk in quell'indice sono memorizzati). Quindi, abusando di questo valore è possibile `free` questo indirizzo poiché sembra essere un chunk di dimensione 0x100. Questo aggiungerà quell'indirizzo all'indice dei chunk di dimensione 0x100 nel tcache.\
|
||||
Quindi, allocando un chunk di dimensione 0x100, è possibile sovrascrivere l'indirizzo del chunk iniziale di altri indici di tcache. Ad esempio mettendo l'indirizzo del malloc hook in uno di essi e allocando un chunk della dimensione di quell'indice si otterrà un chunk nel calloc hook, che consente di scrivere un one gadget per ottenere una shell.
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Impara l'hacking su AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la **tua azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* **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)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di Github.
|
||||
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Attacco al Bin Non Ordinato
|
||||
# Attacco al Bin non ordinato
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -6,15 +6,15 @@
|
|||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* **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)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e ai repository github di [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
|
||||
|
||||
</details>
|
||||
|
||||
## Informazioni di Base
|
||||
## Informazioni di base
|
||||
|
||||
Per ulteriori informazioni su cosa sia un bin non ordinato, controlla questa pagina:
|
||||
|
||||
|
|
@ -22,40 +22,45 @@ Per ulteriori informazioni su cosa sia un bin non ordinato, controlla questa pag
|
|||
[bins-and-memory-allocations.md](bins-and-memory-allocations.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
Le liste non ordinate sono in grado di scrivere l'indirizzo in `unsorted_chunks (av)` nell'indirizzo `bk` del chunk. Pertanto, se un attaccante può **modificare l'indirizzo del puntatore bk** in un chunk all'interno del bin non ordinato, potrebbe essere in grado di **scrivere quell'indirizzo in un indirizzo arbitrario** che potrebbe essere utile per ottenere un leak di indirizzi libc o bypassare alcune difese.
|
||||
Le liste non ordinate sono in grado di scrivere l'indirizzo in `unsorted_chunks (av)` nell'indirizzo `bk` del chunk. Pertanto, se un attaccante può **modificare l'indirizzo del puntatore bk** in un chunk all'interno del bin non ordinato, potrebbe essere in grado di **scrivere quell'indirizzo in un indirizzo arbitrario** che potrebbe essere utile per ottenere un indirizzo libc o bypassare alcune difese.
|
||||
|
||||
Quindi, fondamentalmente, questo attacco permette di **sovrascrivere un indirizzo arbitrario con un numero grande** (un indirizzo che potrebbe essere un indirizzo di heap o un indirizzo libc) come un indirizzo di stack che potrebbe essere leakato o una restrizione come la variabile globale **`global_max_fast`** per consentire di creare bin rapidi con dimensioni maggiori (e passare da un attacco al bin non ordinato a un attacco al bin rapido).
|
||||
Quindi, fondamentalmente, questo attacco permette di **sovrascrivere un indirizzo arbitrario con un numero grande** (un indirizzo che potrebbe essere un indirizzo di heap o un indirizzo libc) come un indirizzo di stack che potrebbe essere rilevato o una restrizione come la variabile globale **`global_max_fast`** per consentire di creare bin veloci con dimensioni maggiori (e passare da un attacco al bin non ordinato a un attacco al bin veloce).
|
||||
|
||||
{% hint style="success" %}
|
||||
Guardando l'esempio fornito in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#principle) e utilizzando 0x4000 e 0x5000 invece di 0x400 e 0x500 come dimensioni dei chunk (per evitare tcaches) è possibile vedere che **oggi** l'errore **`malloc(): unsorted double linked list corrupted`** viene attivato.
|
||||
Guardando l'esempio fornito in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#principle) e utilizzando 0x4000 e 0x5000 invece di 0x400 e 0x500 come dimensioni dei chunk (per evitare i tcaches) è possibile vedere che **oggi** l'errore **`malloc(): unsorted double linked list corrupted`** viene attivato.
|
||||
|
||||
Pertanto, questo attacco al bin non ordinato ora (tra altri controlli) richiede anche di essere in grado di correggere la lista doppiamente collegata in modo che venga bypassato `victim->bck->fd == victim` o non `victim->fd == av (arena)`. Ciò significa che l'indirizzo in cui vogliamo scrivere deve avere l'indirizzo del chunk falso nella sua posizione `fd` e che il `fd` del chunk falso punti all'arena.
|
||||
Pertanto, questo attacco al bin non ordinato ora (tra altri controlli) richiede anche di essere in grado di correggere la lista doppiamente collegata in modo che venga bypassato `victim->bck->fd == victim` o no `victim->fd == av (arena)`. Ciò significa che l'indirizzo in cui vogliamo scrivere deve avere l'indirizzo del chunk falso nella sua posizione `fd` e che il `fd` del chunk falso punti all'arena.
|
||||
{% endhint %}
|
||||
|
||||
{% hint style="danger" %}
|
||||
Nota che questo attacco corrompe il bin non ordinato (quindi anche quello piccolo e grande). Quindi possiamo **usare solo allocazioni dal bin rapido ora** (un programma più complesso potrebbe fare altre allocazioni e bloccarsi), e per attivare questo dobbiamo **allocare la stessa dimensione o il programma si bloccherà.**
|
||||
Nota che questo attacco corrompe il bin non ordinato (quindi anche quello piccolo e grande). Quindi possiamo **usare solo assegnazioni dal bin veloce ora** (un programma più complesso potrebbe fare altre assegnazioni e bloccarsi), e per attivare questo dobbiamo **assegnare la stessa dimensione o il programma si bloccherà.**
|
||||
|
||||
Nota che rendere **`global_max_fast`** potrebbe aiutare in questo caso fidandosi che il bin rapido sarà in grado di gestire tutte le altre allocazioni fino a quando l'exploit non è completato.
|
||||
Nota che rendere **`global_max_fast`** potrebbe aiutare in questo caso fidandosi che il bin veloce sarà in grado di gestire tutte le altre assegnazioni fino a quando l'exploit non è completato.
|
||||
{% endhint %}
|
||||
|
||||
Il codice di [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin\_attack/unsorted\_explanation/index.html) lo spiega molto bene, anche se se si modificano le malloc per allocare memoria sufficientemente grande in modo che non finisca in un tcache, si può vedere che compare l'errore precedentemente menzionato che impedisce questa tecnica: **`malloc(): unsorted double linked list corrupted`**
|
||||
Il codice di [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin\_attack/unsorted\_explanation/index.html) lo spiega molto bene, anche se se si modificano le malloc per allocare memoria sufficientemente grande in modo che non finisca in un tcache, si può vedere che compare l'errore precedentemente menzionato: **`malloc(): unsorted double linked list corrupted`**
|
||||
|
||||
## Riferimenti e Altri Esempi
|
||||
## Attacco di Infoleak al Bin non ordinato
|
||||
|
||||
Questo è in realtà un concetto molto basilare. I chunk nel bin non ordinato avranno puntatori doppi per creare il bin. Il primo chunk nel bin non ordinato avrà effettivamente i collegamenti **FD** e **BK** **che puntano a una parte dell'arena principale (libc)**.\
|
||||
Pertanto, se puoi **mettere un chunk all'interno di un bin non ordinato e leggerlo** (uso dopo la liberazione) o **allocarlo di nuovo senza sovrascrivere almeno 1 dei puntatori** per poi **leggerlo**, puoi ottenere un **leak di info sulla libc**.
|
||||
|
||||
## Riferimenti e Altri esempi
|
||||
|
||||
* [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#hitcon-training-lab14-magic-heap)
|
||||
* L'obiettivo è sovrascrivere una variabile globale con un valore maggiore di 4869 in modo da poter ottenere il flag e PIE non è abilitato.
|
||||
* È possibile generare chunk di dimensioni arbitrarie e c'è un heap overflow con la dimensione desiderata.
|
||||
* L'attacco inizia creando 3 chunk: chunk0 per sfruttare l'overflow, chunk1 per essere sovraffollato e chunk2 in modo che il chunk superiore non consolidi quelli precedenti.
|
||||
* Quindi, chunk1 viene liberato e chunk0 viene sovraffollato in modo che il puntatore `bk` di chunk1 punti a: `bk = magic - 0x10`
|
||||
* Successivamente, viene allocato chunk3 con la stessa dimensione di chunk1, il che attiverà l'attacco al bin non ordinato e modificherà il valore della variabile globale, rendendo possibile ottenere il flag.
|
||||
* È possibile generare chunk di dimensioni arbitrarie e c'è un overflow di heap con la dimensione desiderata.
|
||||
* L'attacco inizia creando 3 chunk: chunk0 per sfruttare l'overflow, chunk1 per essere sovrascritto e chunk2 in modo che il chunk superiore non consolidi quelli precedenti.
|
||||
* Quindi, chunk1 viene liberato e chunk0 viene sovrascritto in modo che il puntatore `bk` di chunk1 punti a: `bk = magic - 0x10`
|
||||
* Quindi, chunk3 viene allocato con la stessa dimensione di chunk1, il che attiverà l'attacco al bin non ordinato e modificherà il valore della variabile globale, rendendo possibile ottenere il flag.
|
||||
* [**https://guyinatuxedo.github.io/31-unsortedbin\_attack/0ctf16\_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin\_attack/0ctf16\_zerostorage/index.html)
|
||||
* La funzione di merge è vulnerabile perché se entrambi gli indici passati sono gli stessi, realloc su di esso e quindi lo libera ma restituisce un puntatore a quella regione liberata che può essere utilizzato.
|
||||
* Pertanto, **vengono creati 2 chunk**: **chunk0** che verrà unito con se stesso e chunk1 per evitare la consolidazione con il chunk superiore. Quindi, la **funzione di merge viene chiamata con chunk0** due volte, causando un use after free.
|
||||
* Successivamente, viene chiamata la funzione **`view`** con indice 2 (che è l'indice del chunk use after free), che **fa trapelare un indirizzo libc**.
|
||||
* Poiché il binario ha protezioni per allocare solo dimensioni maggiori di **`global_max_fast`** quindi non viene utilizzato alcun fastbin, verrà utilizzato un attacco al bin non ordinato per sovrascrivere la variabile globale `global_max_fast`.
|
||||
* Quindi, è possibile chiamare la funzione di modifica con l'indice 2 (il puntatore use after free) e sovrascrivere il puntatore `bk` per puntare a `p64(global_max_fast-0x10)`. Quindi, creando un nuovo chunk verrà utilizzato l'indirizzo di free compromesso in precedenza (0x20) attiverà **l'attacco al bin non ordinato** sovrascrivendo il `global_max_fast` con un valore molto grande, consentendo ora di creare chunk nei bin rapidi.
|
||||
* Ora viene eseguito un **attacco al fast bin**:
|
||||
* Prima di tutto si scopre che è possibile lavorare con **chunk rapidi di dimensione 200** nella posizione di **`__free_hook`**:
|
||||
* La funzione di merge è vulnerabile perché se entrambi gli indici passati sono gli stessi, realloc su di esso e poi lo libera ma restituisce un puntatore a quella regione liberata che può essere utilizzato.
|
||||
* Pertanto, **vengono creati 2 chunk**: **chunk0** che verrà unito con se stesso e chunk1 per evitare la consolidazione con il chunk superiore. Quindi, la **funzione di merge viene chiamata con chunk0** due volte, causando un uso dopo la liberazione.
|
||||
* Quindi, la funzione **`view`** viene chiamata con l'indice 2 (che è l'indice del chunk uso dopo la liberazione), che **fa trapelare un indirizzo libc**.
|
||||
* Poiché il binario ha protezioni per allocare solo dimensioni maggiori di **`global_max_fast`** quindi nessun fastbin viene utilizzato, verrà utilizzato un attacco al bin non ordinato per sovrascrivere la variabile globale `global_max_fast`.
|
||||
* Quindi, è possibile chiamare la funzione di modifica con l'indice 2 (il puntatore uso dopo la liberazione) e sovrascrivere il puntatore `bk` per puntare a `p64(global_max_fast-0x10)`. Quindi, creando un nuovo chunk userà l'indirizzo di free compromesso in precedenza (0x20) attiverà l'attacco al bin non ordinato sovrascrivendo il `global_max_fast` con un valore molto grande, consentendo ora di creare chunk nei bin veloci.
|
||||
* Ora viene eseguito un **attacco al bin veloce**:
|
||||
* Prima di tutto si scopre che è possibile lavorare con **chunk veloci di dimensione 200** nella posizione **`__free_hook`**:
|
||||
* <pre class="language-c"><code class="lang-c">gef➤ p &__free_hook
|
||||
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
|
||||
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
||||
|
|
@ -64,8 +69,22 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
|||
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
</code></pre>
|
||||
* Se riusciamo a ottenere un chunk rapido di dimensione 0x200 in questa posizione, sarà possibile sovrascrivere un puntatore di funzione che verrà eseguito
|
||||
* Per fare ciò, viene creato un nuovo chunk di dimensione `0xfc` e la funzione di merge viene chiamata con quel puntatore due volte, in questo modo otteniamo un puntatore a un chunk liberato di dimensione `0xfc*2 = 0x1f8` nel fast bin.
|
||||
* Quindi, viene chiamata la funzione di modifica in questo chunk per modificare l'indirizzo **`fd`** di questo fast bin in modo che punti alla funzione precedente di **`__free_hook`**.
|
||||
* Quindi, viene creato un chunk con dimensione `0x1f8` per recuperare dal fast bin il chunk inutilizzato precedente in modo da creare un altro chunk di dimensione `0x1f8` per ottenere un chunk fast bin nel **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
|
||||
* Infine, viene liberato un chunk contenente la stringa `/bin/sh\x00` chiamando la funzione di eliminazione, attivando la funzione **`__free_hook`** che punta a system con `/bin/sh\x00` come parametro.
|
||||
* Se riusciamo ad ottenere un fast chunk di dimensione 0x200 in questa posizione, sarà possibile sovrascrivere un puntatore a funzione che verrà eseguito
|
||||
* Per fare ciò, viene creato un nuovo chunk di dimensione `0xfc` e la funzione merged viene chiamata con quel puntatore due volte, in questo modo otteniamo un puntatore a un chunk liberato di dimensione `0xfc*2 = 0x1f8` nel fast bin.
|
||||
* Successivamente, la funzione edit viene chiamata in questo chunk per modificare l'indirizzo **`fd`** di questo fast bin in modo che punti alla precedente funzione **`__free_hook`**.
|
||||
* Poi, viene creato un chunk di dimensione `0x1f8` per recuperare dal fast bin il chunk inutile precedente, quindi viene creato un altro chunk di dimensione `0x1f8` per ottenere un chunk fast bin nel **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
|
||||
* Infine, viene liberato un chunk contenente la stringa `/bin/sh\x00` chiamando la funzione delete, attivando la funzione **`__free_hook`** che punta a system con `/bin/sh\x00` come parametro.
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Impara l'hacking su AWS da zero a esperto con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* **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)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
|
|
|||
Loading…
Reference in a new issue