Débordement d'un octet

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

Autres façons de soutenir HackTricks :

Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !
Obtenez le swag officiel PEASS & HackTricks
Découvrez La famille PEASS, notre collection exclusive de NFT
Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud dépôts GitHub.

Informations de base

Avoir simplement accès à un débordement d'un octet permet à un attaquant de modifier les informations de métadonnées de taille précédentes, permettant de manipuler les chunks qui sont effectivement libérés, générant enfin un chunk qui contient un autre chunk légitime.

Exemple de code :

https://github.com/DhavalKapil/heap-exploitation/blob/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/shrinking_free_chunks.c
Cette attaque ne fonctionne plus en raison de l'utilisation de Tcaches.
De plus, si vous essayez de l'exploiter en utilisant des chunks plus grands (donc les tcaches ne sont pas impliqués), vous obtiendrez l'erreur : malloc(): invalid next size (unsorted)

Objectif

Faire en sorte qu'un chunk soit contenu à l'intérieur d'un autre chunk, de sorte qu'un accès en écriture sur ce deuxième chunk permette de modifier le premier contenu.

Exigences

Débordement d'un octet pour modifier les informations de métadonnées de taille précédentes

Attaque

3 chunks de mémoire (a, b, c) sont réservés l'un après l'autre. Ensuite, le chunk du milieu est libéré. Le premier contient une vulnérabilité de débordement d'un octet et l'attaquant l'exploite avec un 0x00 (si l'octet précédent était 0x10, cela ferait en sorte que le chunk du milieu indique qu'il est 0x10 plus petit qu'il ne l'est réellement).
Ensuite, 2 chunks plus petits sont alloués dans le chunk du milieu libéré (b), cependant, comme b + b->size n'actualise jamais le chunk c car l'adresse pointée est plus petite qu'elle ne devrait l'être.
Ensuite, b1 et c sont libérés. Comme c - c->prev_size pointe toujours vers b (maintenant b1), les deux sont consolidés en un seul chunk. Cependant, b2 est toujours à l'intérieur, entre b1 et c.
Enfin, un nouveau malloc est effectué pour récupérer cette zone mémoire qui va en fait contenir b2, permettant au propriétaire du nouveau malloc de contrôler le contenu de b2.

Cette image explique parfaitement l'attaque :

https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks

Références

https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks