graphelf : un outil d aide à la compréhension de fichiers ELF

Transcription

1 Université Paris 8 Département d Informatique 2 rue de la liberté Saint-Denis Cedex 02 Mémoire de DEA DEA Intelligence Artificielle et Optimisation Combinatoire Paris 8 - Paris 13 graphelf : un outil d aide à la compréhension de fichiers ELF Karine Mordal-Manet Direction : Françoise Balmas 1 octobre 2004

2 2 Remerciements Je remercie Françoise Balmas pour ses conseils avisés, sa compréhension et sa disponibilité, Harald Wertz pour son entousiasme. Je remercie également Philippe Manet pour les heures sacrifiées à mes recherches et sa patiente à toute épreuve, pour sa relecture attentive et sa longue expérience professionnelle. Je remercie Philippe Dague pour sa compréhension.

3 3 Résumé Nous présentons l outil graphelf qui analyse des fichiers exécutables au format ELF pour en extraire les informations qu il contient. Ces informations sont stockées dans un fichier de données et analysées pour fournir différents graphes : un graphe des appels de fonctions un graphe de flot de contrôle pour chacune des fonctions du programme un graphe détaillé, pour chaque fonction du programme, du code désassemblé découpé en blocs représentant le flot de contrôle. graphelf analyse les fichiers au format ELF. Ce type de fichier correspond aux fichiers au format objet définis pour les plates-formes de type Unix. Il s agit des fichiers exécutables, relocalisables ou encore des librairies dynamiques. Un fichier au format ELF est découpé en sections regroupant des informations de même type. Ces sections sont elles-même regroupées en segments qui représentent l organisation de la mémoire lorsque le programme est chargé en mémoire. graphelf utilise ces sections et ces segments pour recueillir les informations du fichier binaire. graphelf recueille entre autres le code désassemblé du programme sous forme d un listing découpé fonction par fonctions. Les graphes fournis permettent ensuite de mieux comprendre ce code désassemblé ainsi que la structure du programme. graphelf exploite ensuite ces informations dans le cadre de la détection de failles de sécurité. Les graphes qu il fournit ainsi que l analyse des informations du fichier binaire permettent ainsi à notre outil de faire ressortir notamment d éventuels débordements de tampons ou bogues de format.

4 4

5 Table des matières 1 Introduction Architecture d un fichier binaire Fonctionnement de graphelf Un fichier binaire ELF vu par graphelf Le fichier de données du programme Test Les graphes du programme Test Plan de lecture Le format ELF Le format objet Les liens avec les librairies Lien statique Lien dynamique Gestion de la mémoire Le chargement en mémoire d un programme L espace d adressage d un processus Organisation de la mémoire La pile et l exécution d une fonction Structure générale d un fichier au format objet Le format ELF L en-tête d un fichier ELF Deux angles de vue Les sections et leur en-tête Les segments et leurs en-têtes La table des symboles et la table des noms

6 6 2.6 La gestion des adresses dynamiques Le segment dynamic L interpréteur de programme La table GOT la table PLT Résolution d un appel dynamique Présentation de graphelf Contraintes techniques Présentation générale de graphelf Les options de graphelf Organisation du programme Fonction de début de graphelf Phase de lecture du fichier ELF Structure de stockage des informations Algorithmes de lecture du fichier Exemple d application avec le fichier gencode : le contenu du fichier ELF Phase de construction des appels de fonctions Lecture du fichier en passant par les noms des fonctions Algorithme de lecture de la table des symboles Lecture du fichier en passant par les adresses des fonctions Algorithme de lecture par les adresses Précisions sur la recherche de l adresse de début de la fonction main et sur celle de fin de programme Algorithme de découpage par blocs Algorithme de recherche des instructions call Graphes des appels de fonction du programme gencode Phase de construction du flot de contrôle des fonctions Découpage de la fonction analysée en blocs Création des liens entre les blocs Cas des sauts vers des fonctions

7 Cas des sauts vers des tables indexées Les graphes du programme gencode Emploi de la bibliothèque dynamique libdisasm Les fonctions de la bibliothèque Algorithme de désassemblage Création de graphes avec graphviz Comparaison avec l existant : les outils dans le même domaine readelf : un outil affichant les informations contenues dans un fichier ELF Les désassembleurs objdump bastard Quelques autres désassembleurs Les outils générateurs de graphes d appels de fonction flowgraph bin2graph elfsh : un outil complet Conclusions Discussion, évolution Discussion - Evolution Modifications d un programme propriétaire Recherche de failles dans un programme : l audit de sécurité Les débordements de tampon Les parades existantes Les recherches de débordements de tampon dans un fichier binaire Les bogues de format Les moyens de défense Fonctionalités cachées d un programme Aide au développement d un logiciel Le format ELF et les virus Exemples d application

8 La liste des bibliothèques dynamiques Les chaînes de caractères Une fonction jamais appelée Mise en évidence de fonctions particulières malloc et free malloc et free non standards Optimisation du compilateur Liste de fonctions suspectes Analyse de strcat Analyse de strcpy Analyse de printf dans la fonction fa Analyse de printf dans la fonction main Analyse de printf dans la fonction fc Conclusion 167 Affinage des analyses dans la recherche de failles de sécurité Amélioration de la compréhension du code désassemblé Limitation de la plate-forme et du compilateur 170 Interface plus facilement utilisable L analyse dynamique du fichier ELF Bibliographie 177 A Un affichage avec readelf 179 B Quelques graphes construits par graphelf 185 C Le code source de graphelf 191

9 Table des figures 1.1 Schéma général des sections d un fichier au format ELF Les principaux segments d un fichier au format objet Correspondance entre les sections et les segments d un fichier ELF Les sources du programme Test Graphe des appels de fonction de Test Graphe du flot de contrôle de la fonction fa du programme Test Graphe des blocs de code de la fonction fa du programme Test Appel de la fonction printf située dans une librairie statique Appel de la fonction printf située dans une librairie dynamique Chargement en mémoire d un fichier au format ELF Schéma général de la mémoire d un programme Schéma général de la pile lors de l appel d une fonction Schéma général d un fichier au format objet Schéma général des en-têtes de sections d un fichier au format ELF Correspondance entre la table des noms et la table des symboles Pointeurs entre la table PLT et la table GOT Appel suivants à une fonction externe Graphe des appels de fonctions du graphelf Algorithme général de graphelf Algorithme principal de lecture du fichier ELF Algorithme de lecture des sections du fichier ELF Algorithme de lecture des segments du fichier ELF

10 Algorithme de lecture par les noms Algorithme de parcours de la section text à la recherche des fonctions Algorithme de découpage du code en blocs de fonctions Algorithme de lecture des instructions call Le graphe des appels de fonctions par les noms de Test Le graphe des appels de fonctions par les adresses de Test Algorithme de recherche des instructions de sauts Algorithme de parcours des blocs construits Graphe représentant une instruction switch Le graphe de la fonction main du programme gencode Le graphe de la fonction main du programme gencode représentée avec le code Algorithme général de désassemblage du code Script GPR utilisé par graphelf Le graphe des appels de fonctions de GG Le graphe de flot de contrôle de GG Le graphe de flot de contrôle de GG généré par bin2graph Le graphe des appels de fonctions de GG généré par graphelf Exemple de débordement de buffer Schéma de la pile lors de l appel de la fonction printf Le code source de l exemple de fonction non appelée Graphe des appels de fonction du programme exemple Graphe décrivant la fonction fa Code source du programme Appel_malloc Graphe des appels de fonction d un programme Graphe de la fonction 0x804839c Code désassemblé du programme Appel_malloc Graphe des appels de fonction Graphe des appels de fonction Graphe de la fonction main du programme Appel_malloc Graphe de la fonction main du programme Appel_malloc, optimisée

11 Graphe des appels de fonctions du programme fn_dout Graphe du flot de contrôle de la fonction fa de fn_dout Graphe du flot de contrôle de la fonction fb de fn_dout Graphe détaillé du code de la fonction fa de fn_dout Graphe détaillé du code de la fonction fb de fn_dout Schéma de la pile lors de l exécution de la fonction fb Graphe détaillé du code de la fonction main de fn_dout.. 165

12 12

13 Liste des tableaux 2.1 Les principales sections ELF Exemple d un segment Text sous Unix Exemple d un segment Data sous Unix Valeurs des drapeaux du segment dynamic

14 14

15 Chapitre 1 Introduction Nous présentons graphelf, un outil d analyse de fichiers binaires ayant pour objectif de fournir une aide dans la compréhension du code de programmes ainsi que dans la recherche de failles de sécurité. graphelf collecte les informations contenues dans un fichier au format ELF sur une plate-forme Intel et les mémorise dans un fichier de données. Ces informations sont ensuite exploitées et analysées pour fournir : Un listing contenant le code désassemblé. Un graphe général des appels de fonction pour l ensemble du programme. Un graphe par fonction détaillant le flot de contrôle 1 de chacune des fonctions. Un graphe par fonction du code désassemblé, découpé selon ce flot de contrôle. Une mise en évidence des fonctions présentant un risque en terme de sécurité. Notre outil constitue une aide à l analyse d un fichier binaire. Cette analyse s avère souvent nécessaire dans différents domaines, par exemple dans le cadre de la sécurité informatique, de la recherche de virus ou encore du développement d un logiciel devant communiquer avec un logiciel commercial. Dans le domaine de la sécurité informatique, lors d un audit de sécurité sur un logiciel propriétaire 2, le code exécutable constitue la seule base de travail. Les techniques d analyse d un fichier binaire 3 servent alors à s assurer, 1. Nous appelons flot de contrôle les boucles et les branchements conditionnels contenus dans une fonction. 2. Nous entendons par ce terme un logiciel pour lequel on ne dispose pas des sources. 3. Ces techniques sont regroupées sous le nom de reverse engineering, cependant ce terme est ambigü. Dans le milieu industriel, il désigne uniquement l analyse de fichier binaire tandis que dans la recherche académique, il recouvre également des techniques d analyse de code source. C est pourquoi nous utilisons l expression analyse de fichier binaire. 15

16 16 par exemple, que le logiciel ne possède pas de fonctionnalités cachées indésirables, qu il ne contient pas de failles le rendant vulnérable à une attaque de pirate ou de virus, ou encore qu il ne possède aucune porte dérobée. Les éditeurs d anti-virus ont également recours en permanence à l analyse de fichiers binaires. En effet, le seul moyen d analyser un virus pour en déterminer la signature et développer ensuite la parade à ce virus passe par la compréhension de ce dernier, dont on ne dispose bien évidemment jamais des sources. Les éditeurs travaillent donc au désassemblage du virus et à la compréhension de ce code désassemblé, souvent obfusqué ou crypté. De même, il peut parfois s avérer nécessaire d analyser des logiciels dont on ne dispose pas des sources, afin d en comprendre les caractéristiques techniques et d établir une compatibilité entre son propre programme et ces logiciels propriétaires. Dans ce cas, l analyse de binaire a souvent comme objectif de recueillir les différentes structures et contraintes sur les données afin d établir la communication entre les deux logiciels. L analyse d un fichier binaire peut également fournir des indications non négligeables telles que la liste des fonctions externes et des bibliothèques nécessaires à l exécution du programme, ce qui peut s avérer utile lors de l utilisation d un programme propriétaire. En effet, ceux-ci sont souvent peu documentés quant à leurs appels de fonctions externes. Les techniques d analyse d un fichier binaire ne peuvent être similaires aux techniques d analyse appliquées sur du code source. En effet, un fichier binaire n est pas constitué uniquement de la traduction du code source du programme en langage binaire. Il contient de nombreuses informations permettant de faire fonctionner ce programme : Des indications sur l emplacement du début du programme. Une image de la mémoire virtuelle du processus créé lors de l exécution du programme Des indications sur les fonctions externes appelées par celui-ci ainsi que sur les librairies nécessaires De nombreuses fonctions d initialisation et de fin de programme ajoutées par le compilateur. Eventuellement, des informations permettant le débogage du programme. De plus, la traduction du code source en langage assembleur effectuée par le compilateur dépend étroitement du niveau d optimisation requis à la compilation ainsi que du compilateur employé. Ainsi, le code assembleur issu de la traduction par le compilateur peut alors soit refléter quasiment exactement le code source si aucune optimisation n a été effectuée ou être à l opposé extrêment différent. C est pour toutes ces raisons que nous avons développé graphelf, un outil qui parcourt l ensemble du contenu d un fichier binaire pour collecter

17 17 les informations nécessaires pour la compréhension du programme. Il fournit de surcroît une aide facilitant la lecture du code désassemblé ainsi que des moyens pour accélérer et orienter les recherches de vulnérabilités dans un programme. 1.1 Architecture d un fichier binaire Figure 1.1 Schéma général des sections d un fichier au format ELF Un fichier binaire est constitué d informations structurées [BWC01] selon une norme prédéfinie 4. Le premier champ d information du fichier nous renseigne sur le type de format du fichier et sur les emplacements des autres informations. Le fichier est ensuite découpé en sections qui regroupent les informations de même type. La figure 1.1 présente les principales sections d un fichier binaire et leur contenu. On constate par exemple que le code 4. Pour le format ELF, se référer à [Com95].

18 18 exécutable à proprement parler est contenu dans une section nommée.text tandis que la table des symboles est contenue dans une section nommée.symtab. Les données globales du programme sont réparties selon leur type : les données de type constante se situent dans la section.rodata, les données initialisées dans la section.data et les données non initialisées dans la section.bss. Toutes les informations contenues dans un fichier au format objet sont ainsi réparties dans des sections et pour les lire, il suffit donc de pouvoir accéder à chacune de ces sections. Figure 1.2 Les principaux segments d un fichier au format objet Dans le cadre d un fichier au format ELF, un autre découpage doit être pris en compte : bien que le fichier soit organisé en sections, il est également découpé en segments. En effet, le format ELF distingue les sections, qui sont utiles lors de la phase d édition des liens statiques 5, des segments qui sont employés lors du chargement en mémoire du programme à exécuter. Les segments regroupent différentes informations du fichier en fonction de leur 5. Il s agit de lier entre eux des fichiers objets pour en faire un exécutable.

19 19 futur chargement en mémoire et reflètent donc l image mémoire du processus créé à l exécution du programme comme le montre la figure 1.2. Chaque segment regroupe plusieurs sections du fichier selon qu elles doivent être chargées ou non en mémoire par exemple, ou encore selon qu elles doivent être accessibles en mémoire en lecture et écriture ou uniquement en lecture. Par exemple, le segmenttext de la figure 1.2 est un segment chargé en mémoire et accessible uniquement en lecture. Il contient entre autres la section.text. Le segment data contient les sections qui doivent être accessibles en mémoire en lecture et écriture. Le fichier représenté dans la figure 1.2 contient également des sections qui ne sont pas incluses à l intérieur de segments telles que les sections liées au débogage ou encore la section.symtab qui contient la table des symboles statique ainsi que la section.strtab qui contient la table des noms qui lui est associée. Ces sections, qui ne participent en aucune façon à l exécution du programme, sont optionnelles dans un fichier exécutable et peuvent donc être ou non présentes. Figure 1.3 Correspondance entre les sections et les segments d un fichier ELF

20 20 Ainsi, un fichier au format ELF contient à la fois des sections et des segments comme le résume la figure 1.3. Il contient également deux tables d en-têtes, sous forme de listes de structures, qui permettent de situer les sections et les segments à l intérieur du fichier (cf. figures 1.1 et 1.2). La table des en-têtes de section pointe vers les sections tandis que la table des en-têtes de programme pointe vers les segments. Cependant lors de son exécution, un programme n accède qu à ses segments. Aussi, les en-têtes donnant les indications sur les sections sont facultatifs et peuvent avoir été supprimées du fichier exécutable. S il est relativement aisé de recueillir toutes les informations contenues dans un fichier binaire en parcourant les sections de ce dernier, il est en revanche plus délicat d obtenir ces mêmes informations lorsque seuls les segments demeurent accessibles. Le code du programme, par exemple, est contenu dans la section.text. Lorsque les en-têtes de sections sont encore présents on peut accéder directement au code puisque l en-tête se référant à la section.text contient l adresse de début et la taille de cette section. En revanche, lorsque la table des en-têtes de section est absente, le passage par la table des en-têtes de programme rend la tâche plus ardue. Le schéma de la figure 1.2 indique que la section.text est contenue dans le segment text, entourée d autres sections. Or, dans ce cas l en-tête du segment text ne fournit que l adresse de début du segment et sa taille. Il faut donc avoir recours à des calculs pour déterminer les adresses de début et de fin de cette section : l adresse de début pour la section.text correspond en fait à l adresse de point d entrée du programme fourni par l en-tête du fichier tandis que l adresse de fin de cette section n est déterminée que grâce à des calculs et déductions dépendants du compilateur utilisé. 1.2 Fonctionnement de graphelf Notre outil, graphelf, est basé sur l organisation des fichiers au format ELF. Il recueille et analyse des informations qu il stocke dans un fichier de données. Il utilise soit les en-têtes de section lorsqu elles sont présentes, soit les entêtes de programme pour accéder aux informations contenues dans un fichier binaire. De même, graphelf utilise la table des symboles pour décoder les informations lorsqu elle est encore présente dans le fichier ou recourt à des algorithmes différents pour pallier si nécessaire son absence et obtenir les mêmes informations. graphelf possède donc trois modes de fonctionnement selon qu il peut : lire les sections et la table des symboles. lire les sections mais pas la table des symboles (dans ce cas il effectue d autres calculs pour récupérer les informations).

21 21 lire les segments parce que les en-têtes de section sont absentes et effectuer des calculs pour récupérer les informations qu il ne peut récupérer de la table des symboles 6. Les premières indications recherchées par graphelf se situent dans les différents champs de la structure d en-tête du fichier, celle-ci étant obligatoirement stockée dans les premiers octets du fichier. Ces champs indiquent entre autres le format du fichier, le type du fichier, la machine sur laquelle il fonctionne, mais également les positions dans le fichier des en-têtes de segment et de section du fichier. Ces dernières informations lui permettent ainsi de situer les en-têtes afin de les analyser. Les sections d un fichier ELF permettent un accès direct aux informations du fichier. graphelf privilégie donc la collecte d informations en parcourant directement les sections. Par contre, lorsque les en-têtes de section sont absentes, et contrairement à d autres outils qui lisent les fichiers ELF tels que objdump [Fre02a], graphelf accède néanmoins aux mêmes informations en exploitant directement les segments et leurs en-têtes qui sont eux obligatoirement toujours présents dans un fichier exécutable. Les tables d en-tête sont réprésentées sous forme de listes chainées de structures (cf et 2.5.4). graphelf lit les octets du fichier binaire qui correspondent à ces listes chaînées et les transcrit de façon à pouvoir les lire directement : il remplace entre autres les champs numériques correspondant à des symboles prédéfinis par les noms adéquats et livre les adresses sous forme hexadécimale afin de pouvoir les comprendre comme des adresses sans ambiguité. graphelf dresse ainsi la liste des segments présents dans le fichier avec leur taille et leur position dans le fichier ainsi que la liste des sections lorsque cela est possible. Ensuite, graphelf utilise deux algorithmes différents pour collecter les autres informations dont il a besoin, selon la présence ou non de la table des en-têtes de section. Dans le cas de la présence d en-têtes de section, graphelf lit les structures des en-têtes pour connaître la position de début et de fin dans le fichier des sections contenant les informations recherchées et pour en lire le contenu. En revanche, lorsque graphelf utilise les segments, il ne peut obtenir ces positions de manière directe. Il analyse alors d abord les informations concernant les segments pour effectuer ensuite des calculs permettant de déduire ces mêmes positions de manière indirecte 7 (cf. partie ). 6. Si les en-têtes de section ont été supprimés (par exemple en utilisant la commande sstrip), la table des symboles a nécessairement été supprimée aussi. 7. Notons que si la manière d accéder aux informations diffère, en revanche, les informations recueillies sont identiques. 8. Nous réservons le terme de section pour désigner les sections contenues dans un fichier au format ELF. C est pourquoi nous utiliserons le mot partie pour désigner les différentes sections de ce mémoire.

22 22 A l étape suivante, graphelf vérifie la présence de tables des symboles pour les décoder le cas échéant. Un fichier ELF contient deux tables des symboles : l une, statique et optionnelle, qui référence les symboles du programme (les noms des variables globales et les noms des fonctions notamment) et la seconde, dynamique et obligatoire, qui contient la liste des fonctions dynamiques appelées par ce dernier 9. Ces tables se situent dans des sections distinctes. Couplées à leurs tables des noms respectives, situées également dans des sections différentes, elle permettent de décoder, lors de la phase de désassemblage du programme (voir ci-dessous), les noms des fonctions utilisées par celui-ci. graphelf recherche ensuite les informations nécessaires à l analyse des appels dynamiques. Celles-ci se situent dans différentes sections et sont accédées directement lorsque la table des en-têtes de section est présente ou par l intermédiaire des informations contenues dans le segment dynamic, dans le cas contraire. Ces informations permettent ensuite de déterminer la liste des fonctions externes utilisées par le programme ainsi que les librairies nécessaires au fonctionnement de celui-ci. Après avoir recueilli les différentes informations contenues dans les sections du progamme 10, graphelf passe au désassemblage du code exécutable. graphelf utilise la librairie libdisasm [lib04] pour transformer le binaire en instructions assembleur (cf. partie 3.7). Lorsque la table des symboles statiques est présente, graphelf la parcourt tout d abord pour décoder les noms des fonctions et récupérer leur adresse et leur taille. Grâce à ces résultats, le désassemblage est ensuite effectué fonction par fonction. En revanche, lorsque la table des symboles est absente, le code du programme est tout d abord entièrement désassemblé pour ensuite être analysé afin de déterminer les adresses de début et de fin des fonctions, les noms de celles-ci ne pouvant être déterminés. A l issue de cette collecte d informations, graphelf procède à différentes analyses aboutissant notamment à différents graphes. Ces analyses sont présentées et détaillées dans la partie suivante, à travers l exemple de l analyse du programme Test contenu dans un fichier nommé test1.c et présenté dans la figure Ces appels concernent toutes les fonctions définies dans des librairies dynamiques (les.so sur les systèmes Unix par exemple). Les appels de fonctions de la librairie standard C comme, par exemple, la fonction printf en font partie. 10. Rappelons que graphelf recueille toutes ces informations, qu il dispose ou non de la table des en-têtes de section : c est le type de parcours du fichier qui varie et non les informations obtenues.

23 23 Programme Test #include <stdio.h> main(){ } int i,a; for(a=0;a<10;a++) { printf("la valeur de a : %d \n",a); fa(a); } fa(int a){ } fb(){ int b; if (a<5) { fb(); } else { b =sqrt(a*80); printf("%d \n",b); } char src[30]; char dst[20]; } fgets(src,30,stdin); strcpy(dst,src); Figure 1.4 Les sources du programme Test. 1.3 Un fichier binaire ELF vu par graphelf Cette partie montre des extraits du fichier de données concernant le programme Test (cf. figure 1.4) analysé par graphelf : les en-têtes les tables des symboles et des noms les chaînes de caractères contenues dans le programme le code désassemblé des fonctions Puis les résultats des analyses effectuées : le graphe des appels de fonctions le graphe de flot de contrôle d une fonction le graphe du code désassemblé représenté sous forme de blocs correspondant à ce flot de contrôle la mise en valeur des appels de fonctions dynamiques dangeureuses

24 Le fichier de données du programme Test Les premières informations recueillies par graphelf sont contenues dans l en-tête du programme dont voici un extrait : Partie I, informations ELF entete du fichier type du fichier : EXEC (Executable file) type de la machine : Intel Ces informations nous indiquent qu il s agit d un fichier exécutable au format ELF pour plate-forme Intel. Ce programme est donc analysable par notre outil. Viennent ensuite les en-têtes de section : les entetes de section nombre d entree 35 index section type adresse taille [ 0] NULL 0 0 [ 1].interp PROGBITS 80480f4 19 [ 2].note.ABI-tag NOTE [ 3].hash HASH [ 4].dynsym DYNSYM [ 5].dynstr STRTAB [ 6].gnu.version VERSYM [ 7].gnu.version_r VERNEED c 64 [ 8].rel.dyn REL 80482dc 16 [ 9].rel.plt REL 80482ec 40 [10].init PROGBITS [11].plt PROGBITS c 96 [12].text PROGBITS [13].fini PROGBITS [14].rodata PROGBITS [15].data PROGBITS [16].eh_frame PROGBITS [17].dynamic DYNAMIC

25 25 [18].ctors PROGBITS [19].dtors PROGBITS c 8 [20].jcr PROGBITS [21].got PROGBITS [22].bss NOBITS c 8 [23].comment PROGBITS [24].debug_aranges PROGBITS [25].debug_pubnames PROGBITS 0 95 [26].debug_info PROGBITS [27].debug_abbrev PROGBITS [28].debug_line PROGBITS [29].debug_frame PROGBITS 0 88 [30].debug_str PROGBITS [31].debug_ranges PROGBITS 0 24 [32].shstrtab STRTAB [33].symtab SYMTAB [34].strtab STRTAB Ces en-têtes sont au nombre de 35, soit le nombre de sections contenues dans le fichier. Chaque en-tête fournit le nom de la section qu il référence, la taille et l adresse de début de celle-ci. Il s agit de l adresse virtuelle dans l espace d adressage du processus (voir partie 2.3.2) et non pas de la position dans le fichier binaire. Parmi les sections de ce programme, nous retrouvons la section.text contenant le code, les sections.data,.rodata et.bss contenant les données, mais aussi les sections.debug* contenant des indications de débogage ou encore les sections.dynsym ou.symtab contenant des tables de symboles 11. Les en-têtes de section étant présentes, graphelf analyse ensuite le fichier grâce à cet accès direct aux sections. Les en-têtes de programme étant toujours accessibles, elles sont donc aussi affichées : les entetes de programme nombre d entree 6 index type adresse t_fichier t_memoire protection [ 0] PHDR x00000c0 0x00000c0 R E [ 1] INTERP 80480f4 0x x R [ 2] LOAD x x R E [ 3] LOAD x x RW [ 4] DYNAMIC x00000d0 0x00000d0 RW [ 5] NOTE x x R 11. Les sections et leur contenu sont détaillées dans la partie

26 26 les sections dans les segments segment 0 segment 1.interp segment 2.interp.note.ABI-tag.hash.dynsym.dynstr.gnu.version.gnu.version_r.rel.dyn.rel.plt.init.plt.text.fini.rodata segment 3.data.eh_frame.dynamic.ctors.dtors.jcr.got segment 4.dynamic segment 5.note.ABI-tag On remarque ici que les segments sont nettement moins nombreux que les sections et qu ils contiennent la plupart des sections de la liste donnée ci-dessus. Les sections qui ne sont pas contenues dans un segment sont celles qui ne participent pas au processus d éxecution du programme. Les différents champs sont : type Certains segments sont de type LOAD à savoir chargeables en mémoire. Un seul segment est de type DYNAMIC, il s agit du segment contenant les informations destinées à retrouver au sein du fichier les données nécessaires à la résolution des appels dynamiques. adresse Il s agit de l adresse virtuelle du segment. t_fichier La taille que le segment occupe dans le fichier. t_memoire La taille que le segment occupe en mémoire. Ces deux tailles peuvent être différentes : par exemple la taille du segment contenant la section des données non initialisées.bss. Ces données n occupent pas d espace dans le fichier alors qu il leur est attribué un espace en mémoire. protection Les segments ont des propriétés d accès : les droits d écriture, de lecture et d exécution combinés. Viennent ensuite les tables des symboles et des noms dont voici un extrait :

27 la table des symboles statique Num: Valeur Taille Type Lien Ndx Nom 1: 80480f4 0 SECTION LOCAL 1 2: SECTION LOCAL 2 67: FUNC LOCAL 12 frame_dummy 68: 0 0 FILE LOCAL ABS crtstuff.c 69: OBJECT LOCAL 18 CTOR_END 70: OBJECT LOCAL 19 DTOR_END 71: OBJECT LOCAL 16 FRAME_END 72: OBJECT LOCAL 20 JCR_END 73: FUNC LOCAL 12 do_global_ctors_aux 74: 0 0 FILE LOCAL ABS /usr/src/packages/build/ glibc-2.3/cc/csu/crtn.s 75: 0 0 FILE LOCAL ABS /usr/src/packages/build/ glibc-2.3/cc/csu/defs.h 76: 0 0 FILE LOCAL ABS initfini.c 77: 0 0 FILE LOCAL ABS /usr/src/packages/build/ glibc-2.3/cc/csu/crtn.s 78: 0 0 FILE LOCAL ABS <command line> 79: 0 0 FILE LOCAL ABS /usr/src/packages/build/ glibc-2.3/cc/config.h 80: 0 0 FILE LOCAL ABS <command line> 81: 0 0 FILE LOCAL ABS <built-in> 82: 0 0 FILE LOCAL ABS /usr/src/packages/build/ glibc-2.3/cc/csu/crtn.s 83: 0 0 FILE LOCAL ABS test1.c 84: 0 0 FILE LOCAL ABS elf-init.c 85: OBJECT GLOBAL 17 _DYNAMIC 86: OBJECT GLOBAL 14 _fp_hw 87: NOTYPE GLOBAL ABS fini_array_end 88: OBJECT GLOBAL 15 dso_handle 89: FUNC GLOBAL 12 libc_csu_fini 90: 80484fa 32 FUNC GLOBAL 12 fb 91: FUNC GLOBAL 10 _init 92: FUNC GLOBAL 12 _start 93: c 16a FUNC GLOBAL UND fgets@@glibc_2.0 94: NOTYPE GLOBAL ABS fini_array_start 95: FUNC GLOBAL 12 libc_csu_init 96: c 0 NOTYPE GLOBAL ABS bss_start 97: c 49 FUNC GLOBAL 12 main 98: c fb FUNC GLOBAL UND libc_start_main@@glibc_2.0 99: NOTYPE GLOBAL ABS init_array_end 100: NOTYPE WEAK 15 data_start 101: c 36 FUNC GLOBAL UND printf@@glibc_ : FUNC GLOBAL 13 _fini 103: c 7c FUNC GLOBAL UND sqrt@@glibc_ : c 0 NOTYPE GLOBAL ABS _edata 105: 80485f0 0 FUNC GLOBAL 12 i686.get_pc_thunk.bx 106: OBJECT GLOBAL 21 _GLOBAL_OFFSET_TABLE_ 107: NOTYPE GLOBAL ABS _end 108: c 4 OBJECT GLOBAL 22 stdin@@glibc_ : NOTYPE GLOBAL ABS init_array_start 110: OBJECT GLOBAL 14 _IO_stdin_used 111: NOTYPE GLOBAL 15 data_start 112: 0 0 NOTYPE WEAK UND _Jv_RegisterClasses 113: FUNC GLOBAL 12 fa 114: 0 0 NOTYPE WEAK UND gmon_start 115: c 30 FUNC GLOBAL UND strcpy@@glibc_2.0 27

28 28 La table des symboles statiques contient les symboles utilisés par le programme avec entre autres le nom des fonctions définies par ce dernier. L analyse des fonctions du programme pourra donc s effectuer en utilisant cette table qui fournit en plus du nom des fonctions leur adresse virtuelle, leur position dans le fichier et leur taille. Le champ Type indique s il s agit par exemple d une fonction FUNC ou encore d un objet OBJECT c està-dire par exemple d une variable globale définie dans le programme. la table des symboles dynamique Num: Valeur Taille Type Lien Ndx Nom librairie 0: 0 0 NOTYPE LOCAL UND 0 local 1: c 16a FUNC GLOBAL UND fgets 120 GLIBC_2.0 2: c fb FUNC GLOBAL UND libc_start_main 120 GLIBC_2.0 3: c 36 FUNC GLOBAL UND printf 120 GLIBC_2.0 4: c 7c FUNC GLOBAL UND sqrt 120 GLIBC_2.0 5: c 4 OBJECT GLOBAL 22 stdin 120 GLIBC_2.0 6: OBJECT GLOBAL 14 _IO_stdin_used 1 global 7: 0 0 NOTYPE WEAK UND _Jv_RegisterClasses 0 local 8: 0 0 NOTYPE WEAK UND gmon_start 0 local 9: c 30 FUNC GLOBAL UND strcpy 120 GLIBC_2.0 La table des symboles dynamiques, pour sa part, référence les fonctions et objets dynamiques du programme. Il s agit des fonctions et des variables définies dans les librairies dynamiques. Le champ librairie nous indique la librairie dont dépend l objet nommé. La liste des librairies requises pour le bon déroulement du programme est la suivante : les librairies requises 1 libm.so.6 51 libc.so.6 graphelf fournit également la liste des chaînes de caractères contenues dans le programme. Ces chaînes correspondent ici aux arguments des fonctions printf du programme. chaines de caractères la valeur de a : %d %d Le code desassemblé du programme est ensuite fourni, fonction par fonction. Voici le code de la fonction main :

29 29 fonction main adresse c C 55 push ebp D 89 E5 mov ebp, esp F 83 EC 08 sub esp, 0x E4 F0 and esp, 0xF B mov eax, 0x A 29 C4 sub esp, eax C C7 45 F mov [ebp-08], 0x D F8 09 cmp [ebp-08], 0x E 02 jle 0x804846b EB 28 jmp 0x B 83 EC 08 sub esp, 0x E FF 75 F8 push [ebp-08] push 0x E8 E1 FE FF FF call printf B 83 C4 10 add esp, 0x E 83 EC 0C sub esp, 0xC FF 75 F8 push [ebp-08] E8 0C call fa C4 10 add esp, 0x C 8D 45 F8 lea eax, [ebp-08] F FF 00 inc [eax] EB D0 jmp 0x C9 leave C3 ret Concernant les instructions call, l adresse de destination a été remplacée par le nom de la fonction lui correspondant. De même, les instructions jmp affichent l adresse de destination du saut et non plus le décalage à effectuer par rapport à la position de l instruction Les graphes du programme Test Pour mieux comprendre le code désassemblé et l architecture du programme, nous nous intéressons ensuite aux graphes fournis par graphelf. Ces graphes permettent notamment une première recherche sur d éventuelles failles de sécurité dans le programme. La figure 1.5 contient le graphe des appels de fonction du programme. Dans ce graphe, les fonctions définies dans le programme sont écrites dans des noeuds ovales tandis que les appels de fonction dynamique sont représentées dans des losanges. Les différentes couleurs des losanges représentent les cas suivants : marron la fonction est une fonction ne présentant aucun risque en terme de sécurité. rouge la fonction représente un risque de débordement de tampon.

30 30 main fa printf fb sqrt fgets strcpy Figure 1.5 Graphe des appels de fonction de Test. bleu la fonction représente un risque de bogue de format. La figure 1.6 donne le flot de contrôle de la fonction fa. Les noeuds ovales représentent les points de départ des branchements : l adresse inscrite dans ces noeuds est celle de début de bloc et correspond également à l adresse de destination du saut. L instruction ret est marquée dans un noeud particulier nommé return afin d identifier les possibles points de sortie de la fonction. Les autres losanges identifient les appels de fonction avec les mêmes codes couleur décrits précédemment pour identifier les fonctions dangeureuses. Les appels des fonctions définies dans le programme sont pour leur part représentés dans des losanges de couleur marron tandis que les appels dynamiques ne représentant pas de risque identifié sont de couleur verte. La figure 1.7 détaille la fonction fa. Le graphe représenté correspond au code désassemblé et découpé en blocs selon le flot de contrôle de la fonction. Chaque noeud contient donc le code correspondant au bloc. On retrouve l adresse de début de chaque bloc qui coïncide avec un noeud du graphe de flot de contrôle décrit précédemment ainsi que les appels de fonction et l instruction return. La figure 1.7 nous indique également que la fonction contient un branchement effectué après une comparaison. Il s agit de l instruction if située à l adresse f et représentée par deux branches distinctes vers deux blocs de code différents : le bloc contenant les instructions à effectuer si le

31 31 0x x80484a1 0x80484a8 fb 0x80484f8 sqrt printf return Figure 1.6 Graphe du flot de contrôle de la fonction fa du programme Test. test est vrai et l autre bloc pour le test faux. Le bloc 80484f8 contient les instructions exécutées après le if, à savoir la sortie de la fonction fa. La fonction printf appelée dans ce programme correspond à une fonction potentiellement dangeureuse car susceptible de produire un bogue de format exploitable à des fins malicieuses (voir partie 4.1). La fonction strcpy est également dangeureuse car elle peut engendrer des débordements de tampon (voir partie 4.1). Ces deux fonctions sont donc affichées d une couleur différente afin de repérer les points vulnérables du programme et d orienter les recherches lors d un audit de sécurité par exemple. Le graphe de flot de contrôle nous renseigne sur les adresses de début des blocs dans lesquels se situent ces appels, tandis que le graphe contenant le code désassemblé permet d analyser ce code et de le situer plus facilement que dans le listing contenant le code désassemblé. 1.4 Plan de lecture Le chapitre 2 décrit les caractéristiques d un fichier au format ELF avec ses sections et ses segments. Le chapitre 3 présente graphelf avec son fonctionnement général ainsi

32 push ebp E5 mov ebp, esp EC 08 sub esp, 0x b 83 7D cmp [ebp+08], 0x f 7F 07 jg 0x80484a a1 E a6 EB 50 call fb jmp 0x80484f a8 83 EC ab 8B ae 89 D b0 C1 E b3 01 D b5 C1 E b b9 DB bc 8D c0 8D F c4 DD 1C c7 E8 A0 FE FF FF 80484cc 83 C cf D9 7D FA 80484d2 66 8B 45 FA 80484d6 B4 0C 80484d F dc D9 6D F df DB 5D FC 80484e2 D9 6D FA 80484e5 83 EC e8 FF 75 FC 80484eb 68 5E f0 E8 67 FE FF FF 80484f5 83 C4 10 sub esp, 0x8 mov edx, [ebp+08] mov eax, edx shl eax, 0x2 add eax, edx shl eax, 0x4 push eax fild [esp] lea esp, [esp+04] lea esp, [esp-08] fstp [esp] call sqrt add esp, 0x10 fstcw [ebp-06] mov ax, [ebp-06] mov ah, 0xC mov [ebp-08], ax fldcw [ebp-08] fistp [ebp-04] fldcw [ebp-06] sub esp, 0x8 push [ebp-04] push 0x804865E call printf add esp, 0x f8 C9 leave fb 80484f9 C3 ret sqrt printf return Figure 1.7 Graphe des blocs de code de la fonction fa du programme Test. que le détail des différentes phases d analyse d un programme au format ELF. Ce chapitre décrit également les outils utilisés par graphelf : la librairie de désassemblage libdisasm ainsi que dot pour la construction des graphes. La dernière partie du chapitre compare différents outils existants actuellement avec graphelf et explique ce qu apporte notre outil. Le chapitre 4 décrit le cadre dans lequel s inscrivent nos recherches, les différentes problématiques pour lesquelles notre outil a été conçu et discute de ses possibles applications. Il montre ensuite les résultats fournis par graphelf dans différents exemples de programmes et décrit comment ces résultats peuvent être interprétés. La conclusion discute des limitations de notre outil et envisage diverses possibilités pour étendre le domaine d analyse de graphelf et affiner les recherches en matière de sécurité.

33 Chapitre 2 Le format ELF Ce chapitre est consacré au fichiers aux format objet. La partie 2.1 définit ce qu est un fichier au format objet. Un fichier au format objet fait généralement appel à des fonctions externes telles que les fonctions définies dans la librairie standard C. La partie 2.2 décrit comment un tel fichier gère ces appels. La partie 2.3 donne les étapes de chargement en mémoire d un fichier au format objet et décrit en particulier la gestion de la pile lors de l exécution d un programme. Il existe différents types de formats objet dépendant essentiellement des plates-formes pour lesquelles ces fichiers sont conçus mais qui suivent tous le même format général décrit dans la partie 2.4. La partie 2.5 s intéresse en particulier aux fichiers de type ELF, sujet de notre étude actuelle. La partie 2.6 pour sa part détaille le principe de résolution des appels dynamiques contenus dans les fichiers au format ELF, en particulier sur plate-forme Intel/Linux. 2.1 Le format objet Lors de la compilation des fichiers source d un programme, le compilateur effectue un certain nombre de tâches [ASU89]. Il fournit tout d abord autant de fichiers objet les fichiers d extension.o sous Unix que de fichiers source qu il transmet à l éditeur de liens. Celui-ci se charge alors de les regrouper pour fournir soit un fichier exécutable soit une librairie dynamique selon les options qui lui ont été spécifiées. Les fichiers objet, appelés également fichiers relocalisables, les exécutables et les librairies dynamiques constituent les fichiers au format objet [SCO00]. Un fichier au format objet désigne un fichier dont la structure et la composition suivent la définition d un type de format objet particulier [Sun02]. 33

34 Les liens avec les librairies Un programme écrit en langage C fait en général appel à des fonctions définies dans la librairie standard [KR92] ou bien encore dans d autres librairies. Dans le cas des fichiers de type ELF les liens avec ces librairies peuvent s effectuer de deux manières différentes : statique ou dynamique. Lors de la constitution du programme exécutable, l éditeur de liens statique 1 ne se comportera pas de la même manière selon la méthode choisie Lien statique Figure 2.1 Appel de la fonction printf située dans une librairie statique. Les liens statiques font référence à des librairies statiques. Dans ce cas, l éditeur de liens statique copie une partie de la librairie référencée directement dans le fichier exécutable [BWC01]. Celui-ci contient alors une section text qui regroupe à la fois l ensemble du code exécutable défini dans le programme source et la copie des fonctions utilisées dans la librairie. Le schéma 1. Il s agit de l éditeur de liens utilisé lors de la compilation du programme, par opposition à l éditeur de liens dynamique chargé de résoudre les appels dynamiques lors de l exécution du programme.

35 35 de la figure 2.1 représente deux programmes prog1.c et prog2.c qui font appel à la fonction printf. Le code exécutable de chacun des programmes contient une copie de la définition de la fonction printf. Tout se passe alors comme si toutes les fonctions étaient directement définies dans le programme les utilisant. Le programme, durant son exécution, ne fait appel à aucun module externe puisque les modules de librairies nécessaires ont été intégrés préalablement à l intérieur du code exécutable. Cette méthode présente cependant les inconvénients d obliger à recompiler entièrement le programme lors d une modification de la librairie [BWC01] et d augmenter le nombre de copies de fonctions usuelles en C de manière critique Lien dynamique Figure 2.2 Appel de la fonction printf située dans une librairie dynamique. Lors de liens dynamiques, l éditeur de liens statique 2 marque les fonctions 2. Lors de la phase de compilation d un programme, le fichier exécutable fourni ne doit plus posséder de référence indéfinie. Or l éditeur de liens statique ne connaît pas les adresses des fonctions dynamiques. Il marque donc ces appels de fonction de manière particulière afin de fournir un exécutable dont toutes les références sont définies.

36 36 externes comme étant des appels dynamiques. Il leur assigne des adresses fixes [Hew01] qui correspondent en fait à des pointeurs vers l éditeur de liens dynamique comme le décrit le schéma de la figure 2.2. Dans ce cas, la résolution des appels des fonctions contenues dans les librairies est retardée : elle n est plus réellement effectuée par l éditeur de liens statique mais par un éditeur de liens dynamique, lors du chargement du programme et durant son exécution [BWC01]. C est pour cela que le fichier exécutable contient un certain nombre d informations dynamiques qui sont chargées en mémoire et qui permettent la résolution de ce type d appel. La partie 2.6 détaille la résolution des appels dynamiques dans un fichier au format ELF. L utilisation de librairies dynamiques facilite la maintenance de celles-ci. En effet, lorsqu une librairie est modifiée, il est inutile de recompiler les programmes lui faisant référence 3 ; il suffit simplement de changer la librairie et les programmes, lors de leurs appels de fonctions dynamiques, la référenceront automatiquement. En revanche, si la librairie est modifiée à des fins douteuses ou encore si un bogue y réside, tous les programmes utilisant cette librairie sont affectés. 2.3 Gestion de la mémoire Cette partie présente des notions de gestion et d organisation de la mémoire lors du chargement et de l exécution d un programme sur une plateforme Unix Le chargement en mémoire d un programme Un programme, pour être exécuté, doit d abord être chargé en mémoire. Cette phase est effectuée par le chargeur de programmes qui crée une image mémoire du programme à partir des informations lues dans le fichier exécutable. Parmi les tâches effectuées, le chargeur copie en mémoire différentes parties du fichier [Lev99], appelées sections (cf. partie 2.5.3) et les répartit dans des segments (cf. partie 2.5.4) tels que réprésentés dans la figure 2.3. On distingue ainsi : Les informations accessibles en mémoire et modifiables par le processus, telles que les données. Ce segment est accessible en lecture et écriture. Les informations accessibles uniquement en lecture, tel que le code du programme lui-même. Ce segment est accessible en lecture et exécution.