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

5.6 KiB

Attaque Large Bin

{% hint style="success" %} Apprenez et pratiquez le piratage AWS :Formation HackTricks AWS Red Team Expert (ARTE)
Apprenez et pratiquez le piratage GCP : Formation HackTricks GCP Red Team Expert (GRTE)

Soutenez HackTricks
{% endhint %}

Informations de base

Pour plus d'informations sur ce qu'est un grand bac, consultez cette page :

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

Il est possible de trouver un excellent exemple dans how2heap - attaque de grand bac.

Fondamentalement, ici vous pouvez voir comment, dans la dernière version "actuelle" de glibc (2.35), il n'est pas vérifié : P->bk_nextsize permettant de modifier une adresse arbitraire avec la valeur d'un morceau de grand bac si certaines conditions sont remplies.

Dans cet exemple, vous pouvez trouver les conditions suivantes :

  • Un gros morceau est alloué
  • Un gros morceau plus petit que le premier mais dans le même index est alloué
  • Doit être plus petit pour aller en premier dans le bac
  • (Un morceau pour empêcher la fusion avec le morceau supérieur est créé)
  • Ensuite, le premier gros morceau est libéré et un nouveau morceau plus grand que lui est alloué -> Le morceau 1 va dans le grand bac
  • Ensuite, le deuxième gros morceau est libéré
  • Maintenant, la vulnérabilité : L'attaquant peut modifier chunk1->bk_nextsize en [cible-0x20]
  • Ensuite, un morceau plus grand que le morceau 2 est alloué, donc le morceau 2 est inséré dans le grand bac en écrasant l'adresse chunk1->bk_nextsize->fd_nextsize avec l'adresse du morceau 2

{% hint style="success" %} Il existe d'autres scénarios potentiels, l'essentiel est d'ajouter au grand bac un morceau qui est plus petit qu'un morceau X actuel dans le bac, donc il doit être inséré juste avant dans le bac, et nous devons pouvoir modifier bk_nextsize de X car c'est là que l'adresse du morceau plus petit sera écrite. {% endhint %}

Voici le code pertinent de malloc. Des commentaires ont été ajoutés pour mieux comprendre comment l'adresse a été écrasée :

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

Cela pourrait être utilisé pour écraser la variable globale global_max_fast de libc pour ensuite exploiter une attaque de fast bin avec des chunks plus grands.

Vous pouvez trouver une autre excellente explication de cette attaque sur guyinatuxedo.

Autres exemples

  • La casa de papel. HackOn CTF 2024
  • Attaque de large bin dans la même situation telle qu'elle apparaît dans how2heap.
  • La primitive d'écriture est plus complexe, car global_max_fast est inutile ici.
  • FSOP est nécessaire pour finaliser l'exploit.

{% hint style="success" %} Apprenez et pratiquez le piratage AWS :Formation HackTricks AWS Red Team Expert (ARTE)
Apprenez et pratiquez le piratage GCP : Formation HackTricks GCP Red Team Expert (GRTE)

Soutenez HackTricks
{% endhint %}