Olivier Benjamin - Test en frelatage (fuzzing) et code binaire : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
(Page créée avec « {{Sujet ter | labo = Laboratoire d'informatique de Grenoble (LIG) | titre = Test en frelatage (fuzzing) et code binaire | equipe = VASCO | encadrants = roland.groz@imag.fr,fa... »)
 
 
(Une révision intermédiaire par un autre utilisateur non affichée)
Ligne 3 : Ligne 3 :
 
| titre = Test en frelatage (fuzzing) et code binaire
 
| titre = Test en frelatage (fuzzing) et code binaire
 
| equipe = VASCO
 
| equipe = VASCO
| encadrants = roland.groz@imag.fr,fabien.duchene@imag.fr,karim.hossen@imag.fr
+
| encadrants =roland.groz groz [http://car-online.fr fabien.duchene] karim.hossen
 
}}
 
}}
 
[[Catégorie:TER]]
 
[[Catégorie:TER]]
Ligne 119 : Ligne 119 :
  
 
=== Conclusions ===
 
=== Conclusions ===
J'ai montré dans ce rapport, qu'il est possible d'envisager différentes façon de mesurer l'efficacité du test en frelatage que la méthode de couverture
+
J'ai montré pendant ce TER, qu'il est possible d'envisager différentes façon de mesurer l'efficacité du test en frelatage que la méthode de couverture
 
d'instructions qui est en général utilisée.
 
d'instructions qui est en général utilisée.
 
J'ai également pu obtenir des résultats concrets sur des programmes simples destinés et écrits dans ce but.
 
J'ai également pu obtenir des résultats concrets sur des programmes simples destinés et écrits dans ce but.

Version actuelle en date du 9 décembre 2013 à 20:32


Test en frelatage (fuzzing) et code binaire

Labo Laboratoire d'informatique de Grenoble (LIG)
Equipe VASCO
Encadrants groz [http://car-online.fr fabien.duchene karim.hossen roland.groz groz fabien.duchene karim.hossen ]

Etudiant

Benjamin Olivier, MMIS-MCS

Introduction

L'équipe VASCO s'intéresse à la validation de systèmes et de logiciels. L'informatique prenant toujours plus d'importance dans notre monde, les logiciels sont amenés à manipuler des données de plus en plus sensibles, et ce de plus en plus fréquemment. L'impact des défauts des logiciels sur l'économie des États-Unis a été estimé à 59.5 milliards de dollars par an. L'amélioration des tests permettrait de réduire ce coût de 22 milliards de dollars par an. Pour cela, une étape est donc de s'assurer qu'un logiciel se comporte conformément à ses spécifications avant sa mise en service. C'est la raison pour laquelle il est nécessaire de tester les programmes de manière plus intelligente et efficace.

Éléments de prérequis

Les prérequis de ce sujet tiennent surtout à la connaissance du vocabulaire du test logiciel, dont voici une partie.

Test logiciel : Le test logiciel est la discipline qui s’attache à vérifier la conformité d'un logiciel vis à vis d'un cahier des charges.

Vulnérabilité : Une vulnérabilité est un défaut, une faiblesse du système considéré qui pourrait résulter en une violation des propriétés du système.

Buffer Overflow : Le buffer overflow est une des vulnérabilité les plus connues. Il s’agit d’un comportement anormal qui permet d’ écrire dans une partie de la mémoire autre que celle prévue, en débordant de cette dernière.

Travail réalisé

Le principe du test en frelatage est de soumettre le programme à des données aléatoires, mal formées --volontairement ou pas--, ou proche de certaines bornes, afin de prévoir son comportement quand confronté à un attaquant. Pour des raisons d'efficacité, il est nécessaire de trouver un moyen d'évaluer la qualité des tests.

Figure 1

La métrique généralement adoptée pour ce faire est la couverture d'instructions: on exécute le programme, et on examine ensuite la quantité d'instructions qui a été exécutée par rapport à la quantité d'instructions totale du programme. Le but de mon TER était d'étudier d'autres métriques possibles. Le principe de l'analyse retenue est dans un premier temps de définir une base de chaînes d'instructions susceptibles d'être utilisées par un attaquant pour détourner le programme de son utilisation. Ceci doit être fait une seule fois, et, dans un cadre plus général, cette base devrait être maintenue et mise à jour au fur et à mesure des progrès faits dans la découverte de vulnérabilités. Ensuite, il convient d'examiner le programme afin de détecter les instructions présentes qui pourraient être utilisées pour aboutir à une séquence présente dans la base. Ceci doit être fait pour chaque programme. On doit ensuite répertorier les chaînes d'instructions qu'il est à priori possible de construire pour ce programme, et leur attribuer une valeur qui permettra à la fin des tests de calculer leur efficacité. Viennent ensuite les tests, pendant lesquels il faut détecter quelles chaînes ont été exécutées, et dans quelle proportion des tests. La dernière étape consiste à évaluer la qualité des tests en fonction des enchaînements qui ont été atteints, et donc testés, ainsi que des proportions des tests qui ont déclenché au moins un de ces enchaînements.

J'ai écrit un script python pour IDA (utilisable grâce à IDApython) qui implémente cette analyse. J'ai dans un premier temps mis en place la version naïve de l'approche des patrons de vulnérabilité, qui consistait à surveiller les appels à des fonctions jugées dangereuses. Le but de cette expérience, est d'arriver à détecter que la dernière branche conditionnelle est la plus intéressante en termes de vulnérabilités.

#include <stdio.h>
#include <stdlib.h>
#include <readline/readline.h>

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

	if(!strcmp(argv[1], "1")){
		printf("le premier argument vaut 1\n");
	}else if (!strcmp(argv[1],"2")){
		printf("le premier argument vaut 2\n");
	}else if (!strcmp(argv[1],"3")){
		printf("le premier argument vaut 3\n");
	}else if (!strcmp(argv[1],"4")){
		char *p = readline(">>>");
		char buffer[20];
		strcpy(buffer, p);
	}
}

Dans ce programme, on constate rapidement que seule la dernière séquence d'instructions, déclenchée par un premier argument valant 4, est suceptible d'entraîner une vulnérabilité, ici de type buffer overflow.

Dans un deuxième temps, on veut cette fois ci tracer les instructions exécutées avant l'appel aux fonctions dangereuses. Pour tester, je me suis concentré sur un exemple simple, où un cherche à detecter les appels éventuels à la fonction strlen de la libc avant les appels à strcpy.

#include <stdio.h>
#include <stdlib.h>
#include <readline/readline.h>

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

	if(!strcmp(argv[1], "1")){
		printf("le premier argument vaut 1\n");
	}else if (!strcmp(argv[1],"2")){
		printf("le premier argument vaut 2\n");
	}else if (!strcmp(argv[1],"3")){
		printf("le premier argument vaut 3\n");
	}else if (!strcmp(argv[1],"4")){
		char *p = readline(">>>");
		char buffer[20];
		strcpy(buffer, p);
	}else if (!strcmp(argv[1],"4")){	
		char *p = readline(">>>");
		char buffer[20];
		if(strlen(p)<19){
			strcpy(buffer, p);
		}
	}else if (!strcmp(argv[1],"5")){
		char *p = readline(">>>");
		char buffer[20];
		strcpy(buffer, p);
	}
}

Dans ce cas précis, l'appel à strlen montre une volonté de tester pour éviter la vulnérabilité de type buffer overflow. Ainsi, il faudrait donner une importance plus grande à l'appel non testé, car on ne sait pas encore s'il est ou non précédé d'une instruction recherchée, et une moins grande à celui déclenché, car il présente moins de chances d'être exploité, puisque le développeur a essayé de se prémunir contre cette possibilité.

Conclusions

J'ai montré pendant ce TER, qu'il est possible d'envisager différentes façon de mesurer l'efficacité du test en frelatage que la méthode de couverture d'instructions qui est en général utilisée. J'ai également pu obtenir des résultats concrets sur des programmes simples destinés et écrits dans ce but. Dans chaque cas, on a pu constater que les résultats obtenus étaient cohérents avec une analyse de vulnérabilité menée par un humain. On peut cependant regretter de n'avoir pas pu tester ces méthodes sur des programmes plus importants

Références

  • [1] G. Erdelyi ; E. Bachaalany ; E. Carrera. idapython - python plugin for interactive disassembler pro. http ://code.google.com/p/idapython/
  • [2] W. Jimenez ; A. Mammar ; A. Cavalli. Software vulnerabilities, prevention and detection methods : A review. Technical report, Telecom SudParis, 2009
  • [3] C. Miller ; Z.N.L. Peterson. Analysis of mutation and generation-based fuzzing. Technical report, Independent Security Evaluators, 2007
  • [4] Martin Vuagnoux. Autodafe : an act of software torture. Technical report, Swiss Federal Institute of Technology, Cryptography and Security Laboratory, 2006
  • [5] A. Lanzi ; L. Martignoni ; M. Monga ; R. Paelari. A smart fuzzer for x86 executables. Technical report, Milan University, 2007
  • [6] Wang ; Wei ; Gu ; Zou. Taintscope : A checksum-aware directed fuzzing tool for automatic software vulnerability detection. Technical report, Chinese ministry of Education, Peking University, Texas A and M University, 2010

Documents additionnels