L'objectif de cette série d'exercices est de comprendre le fonctionnement d'une attaque de débordement de tampon sur le tas. Le programme attaqué est un player qui manipule un fichier. Malheureusement le programmeur suppose que les spécifications du format sont respectées. Il ne contrôle pas la validité de l'entête du fichier joué.
Votre mission, si vous l'acceptez, sera de modifier un fichier valide, afin de faire éxécuter des instructions arbritaires si un utilisateur tente de lire ce fichier avec le programme vulnérable.
Vous trouverez le programme et un 'environnement de travail' dans l'archive suivante : tarball de l'exercice
La première étape consiste à induire le programme en erreur en modifiant les données qu'il va manipuler. Pour cela, vous trouverez dans le code source du programme (vuln.c) la structure du fichier manipulé.
Ce qui est attendu de vous :
Trouver un des bugs du programme. Dans un fichier README, expliquez la nature du bug (1 ~ 2 phrases), et préciser le numéro de la ligne vulnérable.
Modifier le programme crafter.c, afin qu'il génère un fichier qui réalise les conditions pour qu'un buffer déborde et que le programme plante.
Pour réaliser cette partie, il vous est conceillé d'utiliser une redhat 7.2, (malloc est compilé avec les infos de debug). Mettez la source de malloc fournis dans le même répertoire que votre core dump, et gdb vous montrera à quel ligne du fichier ca SIGSEGV, et vous pourrez afficher les variables du code sources.
Axes de recherche
Déjà, il faut savoir ce que vous exploitez, vous allez manipuler soit free (facile) soit malloc (un peu plus dur). La méthode est lègerement différente.
Faite déborder le buffer avec des valeurs dont les 2 bits de poids faible sont mis ou non (pour changer le flag IS_MMAP et PREV_INUSE). Par exemple avec 0x41 et 0x50. Cela s'appel faire du 'fuzzing' .
Puis il faut que vous compreniez la fonction dans laquelle ca segfault, n'hésitez pas à regarder le code en assembleur pour voir les registres que vous contrôlez.
Valider le fait que modifier une adresse (une got, un destructeur, ...) vous permettent de rediriger l'éxecution du programme. Si vous recompilez le programme vulnérable, certaines addresses peuvent changer, faite-le juste pour vérifier la faisabilité.
Faite en sorte que cette addresse soit remplacée par une addresse que vous contrôlez (votre shellcode).
Ensuite repérez les conditions pour que la fonction attaquée se termine correctement. Par exemple, pour free, il va falloir marquer des chunks comme non-utilisées pour éviter que ça fasse n'importe quoi.
Ce qui est attendu de vous :
Que vous comprenniez ce qui se passe. La réussite de cet exercice risque de vous prendre du temps, je ne m'attend pas à ce que vous fassiez un exploit(.c), mais c'est votre démarche qui sera notée.
Modifier le programme crafter.c afin qu'il intégre un shellcode, et faite en sorte que la création de chunk soit bien documentée (si vous utilisez une addresse, mettez ce que c'est (ligne d'objdump)).
Que vous expliquez dans un commentaire ce que vous faite.
Ce dernier exercice est libre, il s'agit d'étudier les différences avec la dernière version de la libc GNU.
Ce qui est attendu de vous :
Que vous repérer les vérifications qui sont faites sur l'intégrité des chunks
Que vous fasiez un 'audit' sur la sécurité de cette version (essayer de faire segfaulter le programme).