Discussion :

[sbill]

Bonsoir,

Je suis sous Mac OS X Yosemite 10.10.3, j'essaye de comprendre la technique du buffer overflow basé sur une pile.
Cependant, mon exemple bien que simpliste ne fonctionne pas car la fonction strcpy me renvoit un abord, est-ce l'OS qui protège la mémoire du programme d'un overflow ?

J'ai essayé de compilé avec gcc -fno-stack-protector mais rien ne change... Comment puis-je testé l'overflow ?

Code :

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

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

Merci pour votre aide.

[Sve@r]

Bonjour

Recopier un contenu plus grand que le contenant (je présume que argv[1] fait plus de 256 caractères) produit un comportement indéterminé donc imprévisible. Néanmoins dans ton cas précis, on peut envisager 2 hypothèses les plus probables:

1. la variable buffer se trouve au milieu de la mémoire de ton programme. Dans ce cas, les caractères qui dépassent 256 continueront à remplir la zone mais comme cette zone reste confinée dans une mémoire qui t'es accessible, il n'y a pas de problème apparent. Bien entendu, si t'as d'autres variables qui utilisent cette zone, leur comportement à elles risque d'être chaotique.
2. la variable buffer se trouve en limite de ta zone mémoire accessible. Dans ce cas, ce qui dépasse 256 essaye de s'inscrire dans la zone mémoire d'un autre processus. Or Os X étant basé sur de l'Unix (très fort verrouillage et indépendance des différents processus), ça plante. Ce n'est pas l'OS qui verrouille (ou plutôt il ne verrouille pas explicitement pour ça) mais ça revient au même et tu ne peux rien y faire.

La technique de buffer overflow fait appel au cas n° 1. Tu écris plus loin que la zone dédiée mais l'écriture peut quand-même se faire. Et en plus il se trouve que ces octets qui dépassent sont interprétés par le processus comme une action (parce qu'ils vont s'inscrire dans la zone dédiée aux instructions ou un truc apparenté). Ca nécessite de connaitre parfaitement le mappage mémoire de ton processus pour faire en sorte que les bons octets tombent où il faut. Très difficile et ça ne se fait pas en mettant des trucs au hasard dans argv[1]...

[Bktero]

J'ai écrit un article sur gets() en montrant comment on peut écraser des données avec un dépassement de tableau : https://gradot.wordpress.com/2013/05...-programmes-c/

Quelle taille fait ce que tu écris dans le buffer ? Sve@r a raison, tu débordes peut-être trop et alors l'OS te gène, mais ce n'est pas à cause de la protection de la pile mais à cause du fait que tu sortes de la mémoire de ton programme.

Si tu essayes d'écrire 258 char par exemple, que se passe t-il ?

[BufferBob]

salut,

essaye en rajoutant les switches -D_FORTIFY_SOURCE=0 et -z execstack à gcc, et il te faudra également désactiver l'ASLR avec une commande du style echo 0 > /proc/sys/kernel/randomize_va_space (en root)

si en débordant "juste un peu" avec 258 comme suggère bktero ça ne fonctionne pas essaye avec un peu plus genre 280 ça doit suffire pour trigger l'overflow

[sbill]

Merci pour vos réponses, à vrai dire je ne test pas vraiment au hasard, j'applique directement les exemples du livre de jon Erickson "Technique de Hacking".
Cependant, moi je segfault toujours là ou lui il ne se passe rien de concret ( mais le programme ne plante pas ).
J'ai essayé avec différentes valeur, cependant ça ne segfault pas uniquement lorsque je ne dépasse pas la taille du buffer.

J'ai bien compris la théorie, je voulais juste voir la pratique.
Je vais essayé/modifier le programme afin d'arriver à mon but.

[sambia39]

Bonjour

Bonsoir,

Je suis sous Mac OS X Yosemite 10.10.3, j'essaye de comprendre la technique du buffer overflow basé sur une pile.
Cependant, mon exemple bien que simpliste ne fonctionne pas car la fonction strcpy me renvoit un abord, est-ce l'OS qui protège la mémoire du programme d'un overflow ?

J'ai essayé de compilé avec gcc -fno-stack-protector mais rien ne change... Comment puis-je testé l'overflow ?

Code :

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

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

Merci pour votre aide.

C'est normale que cela ne marche pas sous le système UNIX où GNU/Linux cette technique a été patcher. Pour faire vos tests-il vous faut désactiver le patch comme dit BufferBob

Code CMD :

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

1
2
3
4
5
(commande  a vérifier )
cat /proc/sys/kernel/randomize_va_space 1
echo 0 > /proc/sys/kernel/randomize_va_space
cat /proc/sys/kernel/randomize_va_space 0

Merci pour vos réponses, à vrai dire je ne test pas vraiment au hasard, j'applique directement les exemples du livre de jon Erickson "Technique de Hacking".
Cependant, moi je segfault toujours là ou lui il ne se passe rien de concret ( mais le programme ne plante pas ).
J'ai essayé avec différentes valeur, cependant ça ne segfault pas uniquement lorsque je ne dépasse pas la taille du buffer.

J'ai bien compris la théorie, je voulais juste voir la pratique.
Je vais essayé/modifier le programme afin d'arriver à mon but.

C'est bien de passer à la pratique après la lecture du livre, mais il est clair dans de tels livres, l'accent est mis en majorité sur un exemple sans aller plus en détaille de façon concrète. En clair, il vous est tout simplement soumis un exemple dans un environnement préalablement formaté en désactivant les patchs de sécurité et en omettant de vous le mentionner tout comme la justification de façon claire et précise sur pourquoi faut-il faire ce débordement de façon maitriser et précise afin d'effectuer des modifications des registres EIP / EBP ( la manipulation des pointeurs dit d'instruction et pointeur de frame) qui est la base de l'exploit et ce qui fait appel a des connaissance assez suffisante du format de fichier ( ELF mais aussi un peu de langage assembleur c'est vieux jeux mais bons) afin d'exploité le fameux bug de gestion de mémoire pour lui faire exécuter des actions qui est pas censé être exécuter; exemple: une élévation de privilège afin d'avoir un shell root.

Ce qui vous a été dit par Sve@r & Bktero sont juste et d'ailleurs ils le disent d'une certaine manière que l'attaque ne peut être qu'un succès a condition de maitriser ce que l'on fait. Donc, savoir exactement de façon maitriser ou placer les instructions de débordement pour réaliser l'attaque ( pas faire n'importe quoi ) en clair, placer votre exécutable en mémoire puis écraser EIP avec l'adresse exacte en mémoire du shell root.

Exemple: admettant que vous souhaiter dans le cadre d'une étude de vulnérabilité, faire un shell root ou une renverse connexion à distance soit, pour exécuter des instructions ou prendre le contrôle de la machine a distance. En temps normal il vous être administrateurs mais vous ne pas posséder ces droits. L'idée va donc d'être, d'exécuter des instructions arbitraire ( injection de code en mémoire) dans un programme qui s'exécute pour effectuer des action avec des droits administrateurs étant qu'un simple utilisateur (donc vous vous élever de façon astucieuse en exploitant la mémoire pour être administrateur de la machine donc, root et là est palpable l'éthique du hacker et ses technique d'hacking).Essayant de revoir le code suivant ( a revoir ).

Code C :

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

1
2
3
4
5
6
 
int main( int argc, char **argv ){
	char t_buff[25];
	(*)strcpy( t_buff, argv[1] );     /* breack point (*) */
	return( EXIT_SUCCESS ); 
}

Pour mieux comprendre sans que l'on aille trop dans les détailles (le reste voir votre livre) nous allons mettre un point d'arrêt sur la fonction de copie afin de comprendre le début de notre exploit, car s'est-elle qui copie les données dans la pile tant qu'un caractère NULL n'a pas été rencontré et ensuite, effectuant le débogage avec 120 caractères "HHHHH" (pour l'exemple) il est clair que l'on déborde largement notre buffer donc, réécriture des pointeurs d'instruction ou frame. Pour réaliser votre exploit en mémoire, vous devez vous arranger pour modifier EIP de façon à vous faire retourner la fonction courante sur une fonction précise exemple "system" et ensuite placer l'argument nécessaire dans l'environnement adéquat pour avoir l'adresse en mémoire du shell root mais pour ça, il faut connaître l'adresse de la fonction "system" et pour connaître cette adresse, il vous faut faire "p system" mais aussi, écrire quelque instruction en langage C pour récupérer la nouvelle variable d'environnement exemple avec l'exportation du shell root ( code a revoir )

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
int main( int argc, char **argv ){
 
	char *ptr_addr = NULL;
 
	/*	teste d'exportation */
	system( "export shell=/bin/sh" );
 
	/*	récuperation des donnée	*/
	ptr_addr = getenv( argv[1] );
	if( (NULL) == ptr_addr ){
		fprintf( stderr, "shell root pas trouver %s\n", 
			strerror(errno) );
		return( EXIT_FAILURE );
	}
        /* affichage de l'adresse mémoire du shell */
	printf( "%s détecté %p\n", argv[1],(void*)ptr_addr );
	return( EXIT_SUCCESS ); 
}

Après toute cette étape, vous pouvez alors construire des arguments ce qui je pense est donnée dans votre livre ( "\x30\ x88etc ...) au final l'astuce consiste à trouver dans le registre "edp" la fonction système et ensuite chercher les arguments nécessaires (eip qui pointe sur "/bin/sh") et le faire retourné dans le programme principale ( le contenue eip ) et de ce fait nous obtenons un shell root.
j'expert vous avoir aidé du mieux que je peux. D'autres membres du forums plus expérimentés pourront répondre à vos questions de manière plus précise
à bientôt

[Médinoc]

Euh, ce livre n'est-il pas censé être livré avec un liveCD contenant un OS (et GCC) vulnérable?

[BufferBob]

Euh, ce livre n'est-il pas censé être livré avec un liveCD contenant un OS (et GCC) vulnérable?

j'ai cru comprendre que si effectivement il doit y avoir un liveCD avec le bouquin permettant de tester, par contre ce n'est pas l'OS et gcc qui sont vulnérables

pour tout le reste et ceux que ça intéresse on trouve de nos jours un peu partout des challenges ssh-based permettant de s'essayer à l'exploitation d'overflows en tous genre avec des protections diverses, en vrac :

• http://smashthestack.org/wargames.html
• http://overthewire.org/wargames/
• https://exploit-exercises.com/
• etc.

[Médinoc]

j'ai cru comprendre que si effectivement il doit y avoir un liveCD avec le bouquin permettant de tester, par contre ce n'est pas l'OS et gcc qui sont vulnérables

Ils sont configurés de manière à l'être (OS avec ASLR désactivé, gcc sans "stack smashing detection"...)