Discussion :

[Tymk]

Bonjour,

J'essaie de comprendre le fonctionnement du processeur x86 pour à terme produire une démonstration sur l'exploitation d'un stack overflow.

Voici les conditions dans lesquelles je travaille :

- J'ai une architecture Intel x86 (processeur Intel Celeron).
- Je travaille sur une machine Debian Squeeze noyau 2.6.32-5-686.
- J'ai désactiver la randomisation de la mémoire.
- Je compile mon programme vulnérable avec l'option gcc "-fno-stack-protector".

Voici le code que je cherche à exploiter (segfault.c):

Code :

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

1
2
3
4
5
6
7
#include <string.h>
int main(int argc, char *argv[]){
	char buffer[512];
	if(argc > 1)
		strcpy(buffer, argv[1]);
	return 0;
}

Voici les tests que j'ai fait :

$ ./segfault $(perl -e 'print "X"x512')
$ ./segfault $(perl -e 'print "X"x516')
$ ./segfault $(perl -e 'print "X"x520')
$ ./segfault $(perl -e 'print "X"x524')
Erreur de segmentation

Et voici ma question :

Pourquoi n'ai je pas de segfault dès lors que j'insère 516 octets ?
Mon buffer fait 512 octets mais la mémoire est allouée aux variables par incrément de 4 octets sur un système 32 bits (4 octets x 8 bits = 32 bits)
Donc, ça devrait planter à 516 octets (les 512 prévus + l'arrondi à 4)

Je pense que quelque chose m'échappe. Pouvez-vous m'éclairer ?

Merci d'avance.

PS: Je me suis posé pas mal de questions avant de choisir ce forum pour poster. J'espère ne pas m'être trompé.

[Tymk]

Mes derniers tests montrent que le même code exécuté sur une machine virtuelle Fedora 9 noyau 2.6.25-14.fc9.i686 (avec un processeur i5 sur la machine hôte) produit le résultat attendu, c-a-d plante à 516 octets.

Il semble donc que cela vienne de Debian ou du la version du noyau. Y aurait-il une protection dont je n'ai pas connaissance ?