Discussion :

[Tibapbedoum]

Bonjour,
Je travaille en ce moment sur les buffers overflow, et j'ai le problème suivant :
Je ne comprend pas pourquoi le programme suivant ne fait pas un overflow "normal" (écrasement de l'adresse de retour, etc.)
Voici le programme en question :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
void t(){
        char tmp[3];
	int i;
        for (i=0; i< 1000; i++) {
		tmp[i]='A';		
	}
}
 
int main(){
       t();
       return 0;
}

Selon moi, et selon gdb, le système d'exploitation reserve 1 octet pour tmp, et 1 octet pour i. Lorsque je remplis ensuite tmp avec des A, il devrait écraser pas mal d'informations, y compris l'adresse de retour, et devrait finalement afficher un magnifique "Segmentation fault in ...".
Voila, mais ce n'est pas le cas, ou bien il faut forcer la boucle a 10000, et encore, le debug avec gdb montre qu'aucun registre n'est affecté !

Alors j'aurais voulu comprendre en quoi mon bout de code plus haut diffère de celui la, avec lequel je n'ai aucun probleme.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
void t(){
       char tmp[3];
       char code[]="AAAAAAAAAAAAAAAAAAAAAAA";
       strcpy(tmp,code);
}
 
int main(){
       t();
       return 0;
}

J'ai pensé au fait qu'il ne stockerait pas les informations au meme endroit (ie pas dans la stack), mais je n'ai rien trouvé sur internet confirmant cette information...
Si vous pouviez m'éclairer.
- Tibap

$ uname -a >> Linux user 2.6.24-27-generic #1 SMP Wed Jan 27 23:54:28 UTC 2010 i686 GNU/Linux
$ gcc --version >> gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

[Fooshi]

1 - Pour commencer le systeme d'exploitation va t'allouer 3 octets pour tmp, 1 char prenant 1 octet en memoire, et un int va te prendre 4 octets (sur un processeur 32 bits).

2 - Comment veut tu faire un overflow avec ton premier code alors que tu pars de temp[0] pour aller a temp[999] ? surtout que ton programme va te jeter car tu n'aura pas alloué un tableau de 1000 caracteres mais seulement 4 !

[ram-0000]

Un excellent article en anglais qui commence à dater un peu maintenant sur les buffer overflow : http://insecure.org/stf/smashstack.html

[Tibapbedoum]

D'abord merci d'avoir pris le temps de me répondre...
@ram-0000 : Oui, je l'ai déjà lu, mais je n'ai pas tout compris, d'où mon poste...
@all : Et bien voici mon raisonnement, merci de me corriger où cela ne colle pas :
Le systeme reserve 3 octets pour tmp. Dans la boucle for, le programme va remplir les 3 octets, puis continuer puisqu'il n'y a aucune vérification de dépassement. Par conséquent, il va continuer à marquer des A en mémoire, écrasant les données placées à la suite : d'où selon moi, un buffer overflow qui devrait marcher...
Je comprend bien que ca ne marche pas, mais je comprend toujours pas pourquoi malgré vos réponses... Si vous pouviez détailler un peu plus ?

[Fooshi]

Teste ca :

Code :

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

1
2
3
4
 
char tmp[3];
char code[]="ABCDEFGHIJKL";
strcpy(tmp,code);

Affiche tmp[0] et tu aura la reponse a ta question ...

[ram-0000]

Le systeme reserve 3 octets pour tmp.

Non, le système te garantit qu'il réserve AU MOINS 3 octets. Il y a de fortes chances qu'il en réserve 4 pour des contraites d'alignement. Il se peut même qu'il en réserve 8 au 16 ou 1024 pour des raisons diverses et variées (optimisations ?).

[sloshy]

Un tableau statique ne sera pas allouer dans le tas, donc je pense pas qu'il va y avoir d'allignement sur 1024 octet

[cmoibal]

Un tableau statique ne sera pas allouer dans le tas, donc je pense pas qu'il va y avoir d'allignement sur 1024 octet

encore un test :

Code :

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

1
2
3
 
char * tmp = malloc(3);
...

[sloshy]

C'est different, le pointeur sera de longueur fixe et pointera sur une zone du tas (et elle sera allignee)

[Tibapbedoum]

Alors, après mure réflexion, voici où j'en suis arrivé :
Si le buffer overflow ne marche pas, c'est tout "simplement" parce que la boucle for ne remplit pas le tableau tmp dans le meme "sens" que strcpy(). Par conséquent, la boucle for écrase bien des données, mais pas les bonnes :-P
Si on print les valeurs de i et de tmp[i] à chaque itération, on a donc :

Code :

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

1
2
3
4
i = 0 et tmp[0] = A
i = 1 et tmp[1] = A
i = 2 et tmp[2] = A
i = 65 et tmp[65] =

Je ne comprend pas maintenant pourquoi ce n'est pas le meme sens que strcpy, mais je suppose qu'il doit y avoir une bonne raison... :S
Merci pour vos réponses en tout cas,
- Tibap.

[sloshy]

Eviter les bufferoverflow pourrait etre une bonne raison?
lis un peu la doc de gcc et regarde la stack guard et les options qui vont avec

[orfix]

Il faut tenir compte du fait que :

• Les OS de nos jours sont très sophistiqués et se prémunissent contre ce genre de débordement.
• Le compilateur peut lui aussi protéger le code contre ce genre de débordement (consulte les options de compilation de ce dernier)

Sinon je te conseille de passer via un pointeur et non un tableau indicé, tu auras certainement plus de chance

[Tibapbedoum]

Oui, en effet, avec les nouvelles versions de gcc, il faut compiler avec l'option -fno-stack-protector, sinon il n'y a aucune chance ;-)

[gl]

Si le buffer overflow ne marche pas, c'est tout "simplement" parce que la boucle for ne remplit pas le tableau tmp dans le meme "sens" que strcpy(). Par conséquent, la boucle for écrase bien des données, mais pas les bonnes :-P
Si on print les valeurs de i et de tmp[i] à chaque itération, on a donc :

Code :

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

1
2
3
4
i = 0 et tmp[0] = A
i = 1 et tmp[1] = A
i = 2 et tmp[2] = A
i = 65 et tmp[65] =

Je ne comprend pas maintenant pourquoi ce n'est pas le meme sens que strcpy, mais je suppose qu'il doit y avoir une bonne raison... :S

Ce qui se produit dans ce cas [1] est assez simple à comprendre. Lorsque tu écris dans tmp[3], tu débordes bien du tableau et du vas écraser ce qui suit, à savoir le byte de poids faible de i ainsi la valeur de i vaut alors 'A' soit 65.

Et la mémoire "comprise" entre t[3] et t[65] n'est pas touchée (contrairement à ce qui se produit en utilisant strcpy().




[1] Et je précise bien dans ce cas, cela peut être différent sur une autre architecture, avec un autre compilateur voire avec des options de compilations différentes.