Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/binary-exploitation/heap/large-bin-attack.md

5.1 KiB
Raw Blame History

Attacco Large Bin

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

Altri modi per supportare HackTricks:

Informazioni di Base

Per ulteriori informazioni su cosa sia un large bin, controlla questa pagina:

{% content-ref url="bins-and-memory-allocations.md" %} bins-and-memory-allocations.md {% endcontent-ref %}

È possibile trovare un ottimo esempio in how2heap - large bin attack.

Fondamentalmente qui puoi vedere come, nell'ultima "corrente" versione di glibc (2.35), non viene controllato: P->bk_nextsize permettendo di modificare un indirizzo arbitrario con il valore di un chunk di large bin se vengono soddisfatte determinate condizioni.

In quell'esempio puoi trovare le seguenti condizioni:

  • Viene allocato un chunk grande
  • Viene allocato un chunk grande più piccolo del primo ma nello stesso indice
  • Deve essere più piccolo quindi nel bin deve andare prima
  • (Viene creato un chunk per evitare la fusione con il chunk superiore)
  • Quindi, il primo chunk grande viene liberato e viene allocato un nuovo chunk più grande di esso -> Chunk1 va nel large bin
  • Quindi, il secondo chunk grande viene liberato
  • Ora, la vulnerabilità: L'attaccante può modificare chunk1->bk_nextsize in [target-0x20]
  • Quindi, viene allocato un chunk più grande rispetto al chunk 2, quindi il chunk2 viene inserito nel large bin sovrascrivendo l'indirizzo chunk1->bk_nextsize->fd_nextsize con l'indirizzo di chunk2

{% hint style="success" %} Ci sono altri scenari potenziali, l'importante è aggiungere al large bin un chunk che è più piccolo di un attuale chunk X nel bin, quindi deve essere inserito proprio prima di esso nel bin, e dobbiamo essere in grado di modificare bk_nextsize di X poiché è lì che verrà scritto l'indirizzo del chunk più piccolo. {% endhint %}

Questo è il codice rilevante da malloc. Sono stati aggiunti commenti per capire meglio come è stata sovrascritta l'indirizzo:

{% code overflow="wrap" %}

/* if smaller than smallest, bypass loop below */
assert (chunk_main_arena (bck->bk));
if ((unsigned long) (size) < (unsigned long) chunksize_nomask (bck->bk))
{
fwd = bck; // fwd = p1
bck = bck->bk; // bck = p1->bk

victim->fd_nextsize = fwd->fd; // p2->fd_nextsize = p1->fd (Note that p1->fd is p1 as it's the only chunk)
victim->bk_nextsize = fwd->fd->bk_nextsize; // p2->bk_nextsize = p1->fd->bk_nextsize
fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim; // p1->fd->bk_nextsize->fd_nextsize = p2
}

{% endcode %}

Questo potrebbe essere utilizzato per sovrascrivere la variabile globale global_max_fast di libc per poi sfruttare un attacco fast bin con chunk più grandi.

Puoi trovare un'altra ottima spiegazione di questo attacco in guyinatuxedo.

Impara l'hacking su AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks: