[Résolu] [BoF] problème adresse de retour

[welc0me]

Bonsoir,

Pour mon premier message sur le forum, je me permet de reprendre une question qui me bloque sérieusement dans mon étude sur les failles applicatives. Je l'avais posée sur deux autres forum, sans réponse. J'espère donc trouver ici une âme charitable qui me permettra d'avancer

J'ai récemment fait l'acquisition du livre "Techniques de Hacking" de Jon Erickson et je suis en ce moment en train d'étudier la partie Exploitation.

Mon but ici est d'effectuer un buffer overflow en utilisant l'environnement.
Pour cela j'ai créé une variable d'environnement SHELLCODE que j'ai remplie avec un tableau de Nop suivi d'un shellcode d'ouverture de shell root.

Le programme ciblé n'est autre que celui présent à ce lien : time0ut (et où la méthode que je veux effectuer y est bien décrite)

Code :

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

void unused_function(void) {
   printf("Impossible => fonction non utilisee\n");
}

void f(const char *s) {
   int i = 1;
   char buffer[12];
   strcpy(buffer,s);
   printf("i = %u\n",i);
}

int main(int argc, char **argv) {
   if(argc != 2) {
      fprintf(stderr,"Usage: buffer_overflow chaine");
      exit(EXIT_FAILURE);
   }
   f(argv[1]);

   return EXIT_SUCCESS;
}

Pour procéder à l'exploitation il faut donc parvenir à changer l'adresse de retour présente dans le bloc d'activation de la fonction f, et la remplacer par une fausse adresse de retour pointant vers le tableau de Nop contenu dans SHELLCODE (ma variable d'environnement).

J'exécute donc mon programme comme cela :

Code :

./buffer_overflow $(perl -e 'print "\x39\xe5\xff\xff\xff\x7f\x00\x00"x20')

(avec 0x7fffffffe539 une adresse pointant vers le milieu du tableau de NOP)

Mais j'obtiens ou rien, ou n'importe quoi.

Je regarde ce qu'il se passe avec gdb et j'obtiens :

Code :

x/20xg buffer
0x7fffffffdfa0: 0xe5397fffffffe539     0xffffe5397fffffff
0x7fffffffdfb0: 0x7fffffffe5397fff     0xe5397fffffffe539
0x7fffffffdfc0: 0xffffe5397fffffff     0x7fffffffe5397fff
0x7fffffffdfd0: 0xe5397fffffffe539     0xffffe5397fffffff
0x7fffffffdfe0: 0x7fffffffe5397fff     0xe5397fffffffe539
0x7fffffffdff0: 0xffffe5397fffffff     0x7fffffffe5397fff
0x7fffffffe000: 0xe5397fffffffe539     0xffffe5397fffffff
0x7fffffffe010: 0x7fffffffe5397fff     0xe5397fffffffe539
0x7fffffffe020: 0xffffe5397fffffff     0x7fffffffe5397fff
0x7fffffffe030: 0xe5397fffffffe539     0xffffe5397fffffff

Alors voici mes questions :

• On remarque un décalage de 2 octets, et on voit que les octets nuls n'ont pas été inscrits dans le buffer, comment cela se fait-il ?
  
• Comment puis-je faire pour réussir cette exploitation ?
  
• Par ailleurs, j'ai remarqué que les adresses mémoires de la pile ont toutes une taille de 8 octets (0x7fffffffe536 par exemple) chez moi, alors que dans de nombreux tutoriels sur internet on ne voit que des adresses de 4 octets (0xbffffce8 par exemple) qui ont l'air de faciliter l'exploitation. Comment cela se fait-il ?
  

J'espère avoir été assez clair...

Merci !

[b0fh]

Hello,

Alors, il y a une petite confusion je crois. Ici le but de l'exercice est, j'imagine, d'appeler la fonction unused_function en écrasant l'addresse de retour de la stack avec celle de unused_function; ce qui ne nécessite pas l'usage d'un shellcode bourré de NOPs, il suffit de répéter l'addresse de retour, ce que fait ton script perl.

Les octets ne sont pas décalés de 2, tu es sur une architecture little endian et les bits les moins significatifs des mots sont alignés correctements. Les \x00 ne sont pas passés à cause de l'expansion du shell, les arguments à un programme étant passés sous forme de null-terminated strings il n'est pas possible d'y inclure des \x00.

Les mots ont une longueur de 8 bytes simplement parce que tu es sur une architecture 64 bits. Tu peux compiler tes exemples en passant -m32 à gcc pour faire des binaires 32bit si tu veux. Si passer en 32bits fait disparaitre les bytes nuls dans l'addresse cible, tu n'auras plus de problème.

[welc0me]

Ah oui ! La confusion est bien là. Cependant la technique que j'ai précédemment décrite m'intéresse aussi, et je comprend maintenant pourquoi ça marchait pas. Merci

Donc si je comprends bien, il n'est pas possible d'exploiter ce type de faille sur une architecture 64 bits c'est ça ? (sans compter l'option -m32 sur gcc)

[b0fh]

Hello,

Si si, c'est possible. Mais le fait d'avoir un 0x00 dans l'addresse cible t'empêche de la passer telle quelle dans une string null-terminated.

Si le programme lisait son buffer sur l'entrée standard au lieu de le prendre dans un argument, par exemple, tu n'aurais pas ce problème.

Pour l'attaque qui consiste a sauter vers un bloc de code existant, tu ne peux pas vraiment controler son addresse, mais si ta cible est de sauter sur un buffer sur la stack, la stack aura généralement une addresse haute, donc pas de 0x00 dans les bytes les plus significatifs; et si par malchance un 0x00 apparait dans les bytes les moins significatifs, si le buffer est assez gros pour te permettre une piste de NOPs confortable, tu peux toujours viser ailleurs dans le buffer, sur un addresse qui ne contient pas de 0.

[welc0me]

D'accord, je pense bien avoir saisi tout ça désormais. Du moins j'espère, avec toutes mes recherches de ce soir !
Bref, j'ai donc cherché à appliquer quelques méthodes (en tenant compte de tes remarques) mais il me reste une dernière question, en rapport avec un bug :

Code :

process 17666 is executing new program: /bin/dash
warning: L'architecture i386:x86-64 sélectionnée n'est pas compatible avec l'architecture cible i386 signalée
L'architecture  du fichier est non reconnu.

Donc je pense que cette erreur arrive lors de l'exécution du shellcode (que j'ai récupéré sur le tuto sur le BoF de N-PN).

Saurais-tu à quoi c'est dû ?

[b0fh]

Hello,

GDB montre que ton process a bien exécuté un shell. Le problème est probablement que tu traçais un processus en 32 bit, mais que le shell que tu as exécuté est en 64, gdb essaie dont de s'y attacher automatiquement, et échoue.

[welc0me]

J'avais en fait compilé en 32bits...
Bon, du coup je viens de réussir ma première exploitation, enfin !
Bref, merci pour ces réponses, et pour la peine +1 rép