Débordement d'un octet

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en é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 le champ size du chunk suivant. Cela permet de manipuler quels chunks sont effectivement libérés, générant potentiellement un chunk contenant un autre chunk légitime. L'exploitation est similaire à double free ou à des chunks qui se chevauchent.

Il existe 2 types de vulnérabilités de débordement d'un octet :

Octet arbitraire : Ce type permet de remplacer cet octet par n'importe quelle valeur
Octet nul (off-by-null) : Ce type permet de remplacer cet octet uniquement par 0x00
Un exemple courant de cette vulnérabilité peut être observé dans le code suivant où le comportement de strlen et strcpy est incohérent, ce qui permet de définir un octet 0x00 au début du chunk suivant.
Cela peut être exploité avec le House of Einherjar.
En utilisant Tcache, cela peut être exploité pour une situation de double free.

Off-by-null

```c // From https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/off_by_one/ int main(void) { char buffer[40]=""; void *chunk1; chunk1 = malloc(24); puts("Get Input"); gets(buffer); if(strlen(buffer)==24) { strcpy(chunk1,buffer); } return 0; } ```

Parmi les autres vérifications, maintenant chaque fois qu'un chunk est libéré, la taille précédente est comparée avec la taille configurée dans les métadonnées du chunk, rendant cette attaque assez complexe à partir de la version 2.28.

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 que l'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

Attaque générale off-by-one

Allouer trois chunks A, B et C (disons de tailles 0x20), et un autre pour empêcher la consolidation avec le chunk supérieur.
Libérer C (inséré dans la liste de chunks libres Tcache de 0x20).
Utiliser le chunk A pour déborder sur B. Abuser de l'off-by-one pour modifier le champ size de B de 0x21 à 0x41.
Maintenant, nous avons B contenant le chunk libre C
Libérer B et allouer un chunk de 0x40 (il sera placé ici à nouveau)
Nous pouvons modifier le pointeur fd de C, qui est toujours libre (empoisonnement de Tcache)

Attaque off-by-null

3 chunks de mémoire (a, b, c) sont réservés les uns après les autres. 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 de 0x10 plus petit qu'il ne l'est vraiment).
Ensuite, 2 chunks plus petits sont alloués dans le chunk libéré du milieu (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

Autres exemples et références

https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks
Bon-nie-appetit. HTB Cyber Apocalypse CTF 2022
Off-by-one en raison de strlen considérant le champ size du chunk suivant.
Tcache est utilisé, donc des attaques générales off-by-one fonctionnent pour obtenir un primitive d'écriture arbitraire avec l'empoisonnement de Tcache.
Asis CTF 2016 b00ks
Il est possible d'abuser d'un off-by-one pour divulguer une adresse du tas car l'octet 0x00 de la fin d'une chaîne est écrasé par le champ suivant.
L'écriture arbitraire est obtenue en abusant de l'écriture off-by-one pour faire pointer le pointeur vers un autre endroit où une fausse structure avec de faux pointeurs sera construite. Ensuite, il est possible de suivre le pointeur de cette structure pour obtenir une écriture arbitraire.
L'adresse de la libc est divulguée car si le tas est étendu en utilisant mmap, la mémoire allouée par mmap a un décalage fixe par rapport à la libc.
Enfin, l'écriture arbitraire est abusée pour écrire dans l'adresse de __free_hook avec un gadget unique.
plaidctf 2015 plaiddb
Il y a une vulnérabilité NULL off-by-one dans la fonction getline qui lit les lignes d'entrée utilisateur. Cette fonction est utilisée pour lire la "clé" du contenu et non le contenu.
Partagez vos astuces de piratage en soumettant des PR aux HackTricks et à HackTricks Cloud dépôts GitHub.

7.3 KiB Raw Blame History