Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-17 06:28:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/binary-exploitation/heap/large-bin-attack.md

5.2 KiB
Raw Blame History

Attaque Large Bin

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

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 morceau1 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 morceau2 est inséré dans le grand bac en écrasant l'adresse chunk1->bk_nextsize->fd_nextsize avec l'adresse du morceau2

{% 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 être en mesure de 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.

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks :