Rédacteur : Heurs
Date de création : 04/07/2006
Section : Sécurité > Failles applicatives
Imprimer cet article : en noir et blanc ou en couleurs
Les Return into libc font partie des techniques d'exploitation des buffer overflows, sous Linux.
Mais pourquoi utiliser le return into libc, étant donné que nous possédons les shellcodes ? La réponse est simple : l'évolution des sécurités. PaX a réussit à rendre la pile non executable :( Dommage... Une parade a été trouvé : les Return Into Libc.
Le programme que nous utiliserons est vulnérable à un bof ; il déborde à partir de l'octet 76. Je vous fait grace de la manière à utiliser pour trouver cette information,référez-vous à l'article sur les Buffer Overflows.
C'est l'objet de cet article, donc il vaut mieux bien cerner déja ce qu'est la libc avant de voir l'exploitation. La libc est une librairie de Linux étant appelé pour l'utilisation de n'importe quel programme (sauf ceux en assembleur bien sur). Elle regroupe la plus part des fonctions les plus courament utilisées (printf, par exemple). Le but sera d'utiliser ses fonctions.
Il existe plusieurs versions de libc, pour le voir un simple listing de répertoire suffit :
On voit trés nettement que libc.so.6 (les .so sont des fichiers contennent des fonctions pouvant etre linkées) est un lien symbolique, donc un ficher pointant vers une version valide de libc (ou tout du moin la dernière).
Le but va etre (comme la pile ne peux etre executée) de sauter directement sur la fonction adéquate. Pour se fair nous devrons donc écraser EIP par l'adresse de la fonction à appeler et déposer les bons arguments sur la pile.
La pile devra donc ressembler à ca (aprés le buffer overflow) :
Nous appelerons tout d'abord la fonction system().
Cette fonction prend un seul argument, l'adresse de la chaine à executer. Nous placerons donc cette adresse juste derrière eip.
Là un premier problème se pose : où trouver la chaine de caractères à executer... Dans la pile, aprés nos arguments, me direz vous (si on la place au début de notre buffer il n'y aura pas de byte terminal). Le seul soucis est que la pile est relativement instable, et des adresses valables dans certaines conditions ne le sont pas forcément dans d'autres (suivant la taille du buffer). J'ai donc opté pour placer cette chaîne dans une variable d'environnement, comme ca elle sera parmi les premières valeurs inscrites dans la pile et cela facilitera grandement nos recherches.
Comme vous le savez, il existe un monde entre la théorie et la pratique, nous allons alors commencer par le plus simple : récupérer les adresses des fonctions.
Les adresse 0x83e58955 et 0x57e58955 sont les adresses des fonctions dans libc. J'ai aussi pris exit, elle nous servira tout a l'heure pour quitter proprement.
Ici nous avons donc placé un breakpoint sur main et lancé le programme, grace à cette action les adresses des fonctions ont été chargées, et nous les avons récupérées juste derrière.
Voici la nouvelle composition de la pile que nous aurons :
Si on se met à la place du programme, cela nous donne la chose suivante. On dépile 0x4005b790, la fonction system croit qu'elle a été appelée par un call et donc croit qu'eip a été empilé. System va donc dépiler la deuxième adresse pointé par esp (soit l'argument). Une fois la fonction terminée celle-ci croit toujours que esp pointe sur une adresse déposée par un call, et donc vas dépiler cette adresse par un "ret". C'est ainsi que la fonction exit sera appelée et donc terminera le programme correctement.
Le but va donc etre maintenant de déposer /bin/sh et de trouver son adresse. Pour exporter la variable d'environement, c'est relativement simple :
Maintenant /bin/sh sera empilé dès l'execution du programme :) Il ne reste plus qu'a trouver son adresse...
Je vous ai facilité la tache pour ca, le programme "src_bin-sh" doit normalement vous indiquer l'adresse de votre variable. Testons ceci :
Nous avons toutes les informations pour mener a bien notre exploitation, alors c'est parti :
C'est pas beau ca ?
Voici la source de src_bin-sh.c (ca peut vous etre utile) :
