Tout le mone a déjà entendu parler du système d’exploitation Linux sans pour autant avoir pris la peine de faire le saut de Windows à celui-ci. De nombreux arguments existent appuyant les avantages d’un système Linux sur Windows, comme par exemple le libre-partage de connaissances, la gratuité de la majorité des distributions et des logiciels, et une communauté d’utilisateurs très active.
Néanmoins, il existe une légende urbaine : « il n’existe pas de vulnérabilités ni de malwares sur un système Linux ». Cette phrase est souvent présentée comme un avantage majeur des systèmes Linux en mettant en avant le fait que Windows soit le système d’exploitation le plus répandu au monde, ce qui implique que le nombre de cibles potentielles est bien plus élevé. Elle est cependant totalement fausse… Voici une étude de la stabilité et de la sécurité des applications Linux par fuzzing.
par Clément SICCARDI et Raphaël PION
Laboratoire (C+V)O , Axe Confiance Numérique et Sécurité/Laboratoire de cryptologie et virologie opérationnelles (ESIEA)
«Il n’existe pas de vulnérabilités ni de malwares sur un système Linux ». C’est faux ! Cette affirmation ignore la prévalence de Linux dans tous les systèmes n’étant pas des ordinateurs personnels (en particulier tous les types de serveurs). De plus, que ce soit pour Windows ou pour Linux, les logiciels sont programmés par des humains faisant naturellement des erreurs, impliquant des vulnérabilités et des failles de sécurité dans ceux-ci.
Fuzzing des applications sous une distribution Linux :
Notre étude consiste à créer une solution générique permettant de tester toutes les applications bureautiques par défaut sur une distribution Linux 64 bits fraîchement installée après mises à jour, et d’en analyser la stabilité et la sécurité.
Pour cela, nous avons mis en place un serveur permettant de lancer en machine virtuelle (en utilisant Virtual Box HeadLess) les distributions Linux à fuzzer en suivant ces étapes :
Nous allons générer un certain nombre de fichiers fuzzés depuis une base de fichiers à l’aide de zzuf [2].
Étude d’un outil de fuzzing « zzuf » :
Zzuf fonctionne avec trois paramètres. Nous avons besoin de préciser la seed (« graine », avec l’option -s) et la range (« portée », avec l’option -r). La range précise le pourcentage du fichier à modifier. La seed est la graine de génération qui est unique et qui permet de reproduire le fichier exact en prenant en compte la range. Soit le flux de données suivant, un texte de 100 caractères (avec le retour chariot ‘\n’ pris en compte).
Figure 3 – Texte de base
En soumettant ce fichier de texte, nous remarquons quelques changements. En effet, nous avons demandé au programme de modifier 1 % de ce flux.
Figure 4 – Texte fuzzé avec zuff (modification de 1 % du flux)
Plus on augmente le paramètre range, plus le contenu du fichier sera modifié.
Figure 5 – Texte fuzzé avec zzuf (modification de 5 % du flux)
Si on met le paramètre range à 1, 100 % du fichier de base sera modifié créant ainsi un nouveau flux ne ressemblant aucunement au fichier de base. Nous avons pu lire dans la documentation de zuff que celui-ci peut suivre en détail le déroulement du programme, cependant cette fonctionnalité n’est pas fiable. En effet, nous avons pu constater que zuff indiquait le mauvais signal de retour (en l’occurrence SIGSEGV). Or lors de l’exécution des fichiers responsables de ces crashes, l’application ciblée ne plantait pas.
Dans le cadre de notre étude, nous avons eu besoin de créer un certain nombre de fichier fuzzés pour chaque fichier de base. Ceci peut se faire à l’aide de zzuf exécutant un script ressemblant à ceci.
Figure 6 – Script en bash permettant la génération de fichier fuzzés
Initialisation du fuzzing d’une distribution Linux invitée sous VirtualBox:
Ensuite, nous devons lancer les machines virtuelles sur lesquelles réaliser notre étude en paramétrant les dossiers de partage (dossier permettant de partager des fichiers entre la machine hôte, en l’occurrence notre serveur, et la machine virtuelle). Sous un système Linux, il sera nécessaire de changer les droits des points de montage du dossier de partage, car par défaut son accès n’est autorisé seulement qu’à l’administrateur. Pour ce faire, il suffit d’exécuter sur chaque machine la commande suivante :
Figure 7 – Commande pour monter le dossier de partage sous Virtual Box avec les droits de USER
Pour chaque machine virtuelle, nous allons lancer en tout trois scripts.
Le premier servira à lister les applications associées par défaut à chaque type de fichier (mime-type). La liste de ces applications se situe pour la majorité des distributions dans « /usr/share/applications/defaults.list ». Le format de ce fichier se présente sous cette forme :
Figure 8 – Format du fichier defaults.list
Il suffit donc d’extraire les applications, leur mime-type et leur version et enregistrer ces informations dans un fichier CSV. Ici, le mime-type est « application/pdf », et « evince.desktop » est le fichier de configuration de l’application à ouvrir par défaut, il contient par exemple la version de celle-ci, ainsi que le format de la commande à lancer lors de l’ouverture.
Le deuxième script servira à associer chaque fichier fuzzé avec son application. Les résultats de cette association seront stockés dans un fichier CSV sous ce format :
Figure 9 – Format du fichier CSV effectuant l’association application-fichier
On note donc l’application, le mime-type, la version ainsi que le fichier fuzzé à tester.
Le troisième script servira à lancer les fichiers avec leurs applications afin de trouver des plantages. Pour plus de rapidité, nous lancerons ces applications en multi-threading, c’est-à-dire qu’on testera plusieurs fichiers en même temps. Le script récupérera enfin le dernier signal de chaque exécution de programme afin de découvrir l’existence d’un crash.
Analyse de la réaction d’une application :
Les signaux de retour qui nous intéressent ici sont ceux impliquant la fermeture brutale de l’application. Nous analyserons ces signaux : SIGSEGV, SIGILL, SIGSYS, SIGBUS, SIGABRT, SIGINT, SIGALRM, SIGSTOP. Pour ce faire, nous utiliserons le programme strace afin de repérer ces signaux en fin d’exécution. Voici un exemple d’utilisation de strace :
Figure 10 – Exemple d’utilisation de strace sur une application quelconque
En observant le fichier comprenant les résultats de strace, nous pouvons nous apercevoir que l’application a planté suite à un SIGSEGV. Ce qui peut éventuellement révéler l’existence d’une vulnérabilité.
< /span>Figure 11 -Résultat de la commande strace lorsqu’un SIGSEGV est détecté
Le résultat du fuzzing est envoyé par mail pour chaque machine et se présente sous la forme d’une liste avec un récapitulatif comportant le nombre de plantages par type de fichier. Nous conservons via un dossier partagé avec le serveur les fichiers responsables ainsi que leurs originaux afin de les analyser.
Exemple d’analyse, Les lecteurs PDF :
Concernant les résultats de cette expérience sur les distributions Linux 64 bits. Nous avons pris un ensemble de PDF comme fichiers de base. Nous les avons fuzzé 100 fois ce qui a produit un total de 9409 fichiers.
Figure 12.1 – Classement des distributions par rapport au nombre de plantages de l’application PDF par défaut
Figure 12.2 – Récapitulatif des signaux de retour pour chaque fichier PDF testé (9409 au total) pour chaque distribution
Comme le PDF est un format très répandu afin de partager des documents, les lecteurs sont des vecteurs principaux d’attaque. Nous avons pu établir un classement des lecteurs PDF par défaut les moins vulnérables pour chaque distribution.
Nous avons décidé de classer ces distributions par nombre de crash, bien que les SIGSEGV puissent être les plus dangereux.
Afin de comprendre ces résultats, nous avons comparé les fichiers responsables d’un crash pour chaque distribution.
Nous observons qu’il y a de fortes similitudes entre les fichiers causant ces arrêts (Figure 14) entre ces distributions, mais moins de similarités entre les signaux de retour de ces arrêts (Figure 15). Pourtant en comparant les fichiers responsables d’un crash ainsi que la nature du signal de retour pour chaque distribution, Nous observons qu’il y a des similitudes entre chaque système de gestion de paquet.
Figure 14 – Comparaison des fichiers responsables d’un crash et des signaux de retour pour chaque distribution. Colonnes comparées avec lignes.
En effet, les logiciels issus des paquets Debian (distributions Ubuntu, Debian, Fedora) se ressemblent, impliquant qu’un fichier faisant crasher le lecteur PDF sur une distribution utilisant un système de gestion de paquets Debian aura de grandes chances de faire crasher les lecteurs utilisant le même système, même si par exemple le lecteur PDF evince sur Ubuntu ne sera pas exactement pareil que le lecteur evince sur Debian. Similairement, on remarque que les distributions utilisant un système de paquets différent, comme RedHat, proposent des crashes similaires entre eux.
Conclusion de ces résultats :
On peut constater qu’Ubuntu est une distribution très répandue sans pour autant être la plus sécurisée. Nous avons pu mener cette étude sans pour autant connaître en détail le format PDF. Le fuzzing a donc permis de trouver plusieurs crashes de manière automatique. Il ne reste plus qu’à trouver une exploitation afin de prévenir les concepteurs de ce logiciel.
On peut interpréter ces résultats en remarquant que malgré le fait qu’Ubuntu soit une des distributions Linux les plus utilisées, elle ne possède pas nécessairement les applications bureau (en l’occurrence le lecteur PDF) les plus stables.
On constate aussi qu’un même logiciel ne sera pas forcément exactement le même dans deux distributions différentes (ici, nous observons des crashes différents sur le même programme selon la distribution utilisée). Pourrions-nous en conclure qu’il existe des différences d’un point de vue sécurité et stabilité au niveau du noyau de chaque distribution Linux ?
Bibliographie :
[1] http://insecure.org/stf/smashstack.html (Aleph One, 1996)
[2] « Fuzzing brute force vulnerability discovery » (H. D. MOORE, 2007)
[3] zzuf, outil de fuzzing, http://caca.zoy.org