hacktricks/binary-exploitation/libc-heap/large-bin-attack.md

5.4 KiB

Attacco Large Bin

{% 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
{% endhint %}

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, nella più recente versione "corrente" 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 sia 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.

Altri esempi

  • La casa de papel. HackOn CTF 2024
  • Attacco large bin nella stessa situazione come appare in how2heap.
  • La primitiva di scrittura è più complessa, perché global_max_fast è inutile qui.
  • FSOP è necessario per completare lo sfruttamento.

{% 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)

Supporta HackTricks
{% endhint %}