Blog Haypo

Après 3 versions béta, le projet Fusil est enfin sorti en version 1.0 ! La version 1.0beta3 a été annoncée dans un journal linuxfr, et sur les listes de diffusions Full Disclosure et Pen test.

Nouveautés de Fusil 1.0

Entre la version 0.9.1 et la 1.0, la liste des changements est longue, mais voici les plus importants :

• Fusil exécute maintenant les processus fils sous un autre utilisateur UNIX (fusil) pour éviter qu'il supprime vos fichiers ou tue vos processus !
• Création d'un script replay.py pour pouvoir rejouer une session. Il permet de rejouer une session dans gdb, Valgrind ou gdb.py.
• Possibilité de créer un fichier de configuration (~/.config/fusil.conf) pour modifier de nombreuses options (ex: désactiver le débogueur)
• Renomme le dossier d'une session avec le type d'erreur pour pouvoir regrouper les sessions similaires (ex: « invalid_read-null », « div_by_zero », « timeout », etc.).
• Chaque fuzzer est un programme qui a ses propres options en ligne de commande : utilisez l'option --help pour obtenir l'aide de chaque fuzzer
• Création de fusil-vlc : teste le lecteur multimédia VLC
• Création de fusil-zzuf : réutilise la bibliothèque zzuf de Sam Hocevar. Contrairement aux outils Fusil, zzuf mute les fichiers en mémoire, ce qui est plus rapide et permet de travailler avec de très gros fichier (plusieurs giga-octets).
• Support de Python 3000 avec le script de conversion conv_python3.0.sh qui utilise le programme 2to3 puis applique quelques patchs supplémentaires
• Support minimal de Windows

Fusil fonctionne sous Linux, FreeBSD et Windows. Il nécessite Python 2.4, supporte CPython et PyPy. Des paquets Debian, Mandriva, et d'autres distributions Linux sont disponibles.

Article dans le magazine MISC

J'ai écrit l'article « Pratique du fuzzing avec Fusil » dans le dernier numéro du magazine MISC (#39). L'article fait parti du dossier dédié au fuzzing.

D'ailleurs, j'ai bien aimé aimé l'article sur Sulley (fuzzer similaire à Fusil) de Gabriel Campana et Laurent Butti (deux dingues de fuzzing qui vous envoyent des exploits noyaux par le wifi !). J'y ai appris qu'ils ont réutilisé python-ptrace (binding Python de ptrace) pour porter Sulley sous Linux.

J'ai commencé à m'intéresser au fuzzing en avril 2007 alors que je testais la solidité de mon projet Hachoir. J'ai ensuite écrit divers scripts bash, puis Python, pour fuzzer d'autres programmes. Perfectionniste, j'ai commencé en novembre dernier à réécrire tous mes scripts depuis zéro en partant sur une nouvelle architecture basée sur un système multi-agents. Deux mois plus tard, j'ai fini de réécrire tous les scripts (Mplayer, ClamAV, Firefox, etc.). Pour marquer le coup, j'ai publié la version 0.7 du projet Fusil.

Nouveautés de la version 0.7

• Projet Firefox utilisant un serveur HTTP écrit depuis zéro, un processus Firefox, et un agent qui envoie la touche F5 à Firefox
• Début du portage sous Windows : Fusil devrait maintenant fonctionner sur Linux, *BSD et Windows
• Corrections du système multi-agents et divers bugs mineurs

La complexité du scénario du projet Firefox montre que Fusil est maintenant prêt pour n'importe quel type de scénario :

• Exécution d'un processus Firefox
• Génération d'images invalides (ou n'importe quel type fichier, comme un animation Flash)
• Exécution d'un serveur HTTP : port TCP 8080 en écoute, puis réponse aux diverses requêtes du navigateur web
• Envoi de la touche F5 à Firefox pour rafraichir l'affichage

Chaque étape est activée à la fin de la précédente, ce qui se décrit simplement avec les événements Fusil (session_start, mangle_filenames, http_server_ready, ...).

Fusil gagne en fonctionnalités

L'idée de Fusil est de simplifier l'écriture d'un projet de fuzzing. Il suffit de décrire le scénario pour préparer et surveiller l'environnement, sans avoir à s'occuper des détails techniques (rediriger la sortie du processus, détecter un plantage, etc). Fusil va plus loin en offrant des fonctionnalités communes à tous les projets :

• Reconnaissance des comportements anormaux : utilisation excessive du processeur (+75% durant 3 secondes), motif de texte dans la sortie standard ou logs Linux (« assertion », « segfault », « glibc detected », ...)
• Recherche automatique des paramètres optimaux capables de planter une application (en particulier, le nombre d'erreur injectées dans un fichier valide)
• Protection du système d'exploitation : limitation des ressources (mémoire / temps) des processus crées, copie partielle des variables d'environnement, etc.
• Pause pour attendre que la charge de la machine retombe sous un certain seuil (CPU à 50%)
• Création d'un dossier temporaire pour chaque session (exécution) du projet, sauvegardé en cas de succès
• Fichier de log contenant l'ensemble des commandes permettant d'analyser un crash voir de rejouer le scénario manuellement

Dans sa version 0.7, Fusil offre des outils pour compiler du code C, créer et surveiller des processus, des clients et serveurs réseaux non blocants (en particulier, un serveur HTTP), etc.

Début mai (2007), je commençais ma campagne intensive de fuzzing comme en atteste mon tableau de chasse. Ce billet est un bilan sur ces deux derniers mois.

Projet Fusil

Depuis le temps, mon outil de fuzzing a trouvé un nom grâce à l'intellect de Feth : « Fusil ». Je suis fier de lui avoir attribué un nom français, qui plus est, a un sens : arme explosant (à) la gueule des programmes :-) En bonus, les anglophones s'y retrouvent à l'oreille (fusil / fuzzy). Le projet habite désormais à cette jolie adresse : fusil.hachoir.org qui pointe vers le duo gagnant, Trac & Subversion. L'outil en lui même a quelque peu évolué : limitation de la mémoire, possibilité de fuzzer les variables d'environnement, détection automatique des variables et fichiers accédés, opérations d'insertion et de suppression pour mangle, etc. Fusil n'est pas encore utilisable en l'état par un novice vu son manque de flexibilité mais j'y travaille.

J'ai eu l'honneur de présenter mon projet au SSTIC, mais les quatre minutes allouées ne m'ont pas suffi. Je pense néanmois avoir dit l'essentiel. J'ai donné la même présentation mais en entier et plus détendu (mais malade) deux jours plus aux Journées Python 2007. Le PDF de la présentation est consultable en ligne depuis le site web du SSTIC.

Ma déception de ClamAV

Autant le nombre de bogues trouvés par Fusil augmente, autant ma motivation pour améliorer les logiciels libres diminue. Je suis plutôt déçu par les réponses données par certains mainteneurs de projet : ils n'ont que faire des bogues de sécurité, ils veulent à tout prix des performances et des fonctionnalités.

J'ai trouvé un bogue assez critique dans l'anti-virus ClamAV : un document Word utilisant 2 Go du disque dur et une bonne partie du CPU durant plusieurs minutes. Il suffirait d'envoyer plusieurs fois ce même fichier (ou des variantes) pour mettre à genoux n'importe quel serveur ClamAV. J'ai posté ma découverte sur leur liste de diffusion en évitant de donner trop de détails, mais suffisament pour être crédible. Et bien, les réponses ne se sont pas fait attendre. En deux heures, trois développeurs m'avaient contacté... pour me gronder car j'avais fait du « full disclosure » (diffusion publique d'une faille de sécurité).

Je me suis excusé et j'ai reposté la faille sur leur outil de suivi des bogues en donnant cette fois tous les détails (étant donné que l'accès à l'outil est protégé). Je me suis dit que le bogue serait corrigé rapidement. Effectivement, en un jour un correctif était disponible. Je pensais qu'ils allaient sortir immédiatement une nouvelle version (étant donné mes révélations publiques)... que nenni. Ils ont attendu plus d'un mois pour publier une nouvelle version (0.90.3). Pourtant, entre temps l'information a été relayée sur les sites frsirt.com et secunia.com.

Avant hier, j'ai relancé une campagne de tests pour vérifier que le format OLE2 était sain. J'ai trouvé trois nouveaux bogues dont un qui est apparu dans la version 0.90.3 (bogue dans le correctif du problème que j'avais soulevé, quel comble !). Je suis allé jusqu'à écrire un correctif pour chaque bogue. Je l'ai fait pour accélérer la correction de ClamAV et pour pouvoir poursuivre mes tests. Après 2 jours, toujours aucune réponse à mes rapports de bogues. Quelle déception par leur manque de réactivité...

Autres déceptions

ClamAV n'est pas le seul projet à manquer de réactivite face aux vulnérabilités : les bogues libpoppler et libexif n'ont pas bougé d'un poil depuis que je les ai rapporté (il y a deux mois).

J'ai l'impression que le public visé (serveur d'entreprise ou application pour particulier) et le fait que j'écrive un correctif ou non importent peu. En fait, je ne sais pas comment faire réagir les mainteneurs pour qu'ils daignent m'accorder un peu de leur temps si précieux.

La lutte continue ! (gimp, mplayer, ...)

Histoire de me changer les idées, j'ai testé les logiciels très populaires que sont Gimp et Mplayer. Après une bonne heure de peaufinage de Fusil, j'ai commencé ma liste de bogues. En environ quatre heures, j'ai trouvé une dizaine de bogues sur chaque logiciel : dénis de service (CPU ou mémoire) ou plantage. Certains sont peut être exploitables.

J'avoue que je voulais vérifier que Secunia avait bien fait son travail en auditant Gimp. Secunia publiait avant-hier une vulnérabilité dans Gimp pour le format PSD. Et bien j'ai trouvé des « vulnérabilités » pour les formats BMP, ICO, PCX, PSD, TUB, XCF. Certains plantages semblent graves.

Histoire de savoir où j'en suis, j'ai commencé une liste des logiciels testés. Il faut maintenant que je prenne mon courrage à deux mains pour rapporter tous les bogues trouvés aux mainteneurs des projets... et espérer qu'ils daignent s'y intéresser.

Livre sur le fuzzing

Pour finir, je voudrais partager mon impatience : le livre Fuzzing: Brute Force Vulnerability Discovery de Michael Sutton, Adam Greene et Pedram Amini me semble sacrément intéressant. Seul hic : il n'est pas encore publié bien qu'il devrait l'être. O'Reilly le vend déjà sous format électronique dans sa boutique Safari. Je devine que l'éditeur donne sa chance aux ebooks avant de sortir la version papier. Raison marketing ou technique : qu'importe, je veux toucher ce livre ! Je pense que je l'achèterai chez le libraire Le Monde en Tique histoire de ne pas me ruiner en frais de port.

Mot(s) de la fin : « Le fuzzing est en pleine effervescence et je m'amuse follement avec ! »

Mes félicitations aux personnes qui ont supportées la lecture pénible des mes complaintes.

Du fuzzing, toujours plus de fuzzing ! Plus je triture les programmes et plus je trouve de bugs. Je n'ai pas encore assez de recul pour dire si c'est positif ou non. En tout cas, je n'arrête pas de publier des rapports de bugs.

Un collègue m'a conseillé de contacter des organismes s'occupant de diffuser les vulnérabilités pour que tous les gens concernés soient au courant et prennent les dispositions nécessaires. Le premier, FrSIRT, m'a répondu en 2h et le second, Securina, en 4h. Chapeau ! Et après quelques échanges d'emails pour leur donner des détails, deux bulletins de sécurité ont été publiés :

• Libexif Image Handling Integer Overflow Vulnerability (10 mai)
• ClamAV OLE2 Parser Denial of Service (11 mai)

Je ne suis pas peu fier de lire mon nom sur ces sites Internet :-) Le bug ClamAV (anti-virus libre pour Windows et Linux) est inquiétant car aucun nouvelle version n'a été publiée pour le corriger. Si ce bug est exploité, il peut rapidement mettre un serveur anti-virus hors-service : consommation massive de ressource processeur et de disque dur.

Je suis de plus en plus persuadé que tous les programmes sont bogués et qu'un certain nombre de bugs sont exploitables par des pirates informatiques. Ce n'est vraiment pas rassurant car tous les types de documents sont affectés. Pour ne citer que les plus courant : on peut planter un programme avec un simple document PDF voir même une image JPEG !

Je cherche et je rapporte les bugs pour contribuer au libre mais également pour éviter que des pirates le fassent à ma place et exploitent les bugs. Comme je n'aurai jamais le temps de tester tous les programmes, je pense plutôt à publier mes outils de test pour que d'autres poursuivent mon travail. J'ai déjà commencé par mettre en place un serveur Subversion ainsi qu'une plateforme Trac pour publier mon travail. Mon nouveau projet est hébergé sur mon serveur perso à l'adresse : fusil.hachoir.org. Consultez mon tableau de chasse : liste des bogues trouvés par la méthode du fuzzing.

Suite de mon initiation au fuzzing. J'ai continué des tests pour trouver toujours plus de bug. J'avais lu par-ci par-là que les programmes ont de très nombreux points d'entrée, pas uniquement le clavier et la souris. J'avais testé les fichiers, j'ai alors testé les variables d'environnement. J'ai d'abord écrit un script bash utilisant strace (puis ltrace) pour traquer les appels à getenv() (entre autres). À partir de la liste des variables, j'en tenté de faire planter les programmes en passant des valeurs invalides (grand nombre, très longue chaîne, etc.). Le premier programme à planter était dpkg avec « COLUMNS=10000000 dpkg -l ».

J'ai mis une bonne grosse semaine à isoler le bug. J'ai compris que le bug venait de vfprintf() mais je n'ai pas compris dans quel cas on pouvait le reproduire. J'ai isolé la chaîne de formatage : on peut alors reproduire le bug avec la fonction printf de bash ou /usr/bin/printf : « printf "%-1.25000000s" "Hello" ». En creusant encore plus, jusqu'à l'assembleur (on peut pas creuser plus profond :-)), j'ai isolé la ligne C qui posait problème. C'était un appel à mbstowcs() utilisant un tampon local de la forme « wchar_t ignore[prec]; », or prec vaut 25000000. En clair : la glibc tente d'allouer 25 Mo dans la pile alors qu'elle fait que 8 Mo et que Linux ne sait pas la faire grossir automatiquement (honte à lui). Je pensais justement que c'était un appel à alloca() mais je faisais fausse route. Conclusion : utilisez la pile avec parcimonie. Évitez absoluement la fonction alloca() et la notation C « type var[taille]; » où taille est supérieur de 4096 ou une variable contrôlable directement ou indirectement par l'utilisateur.

J'ai rapporté le bug et il a été corrigé en 48h par Ulrich Drepper (mainteneur de la libc). Encore une belle preuve de la réactivité des développeurs de logiciel libre.

Le fuzzing est un outil de test logiciel qui consiste à injecter des données incorrectes pour rechercher des erreurs dans un programme, plus particulièrement dans le but de trouver des failles de sécurité. Aujourd'hui (en 2007), cette méthode est extrêmement efficace ! Disons que globalement, aucun programme ne résiste au fuzzing : ils finissent tous par montrer des faiblesses (qui se manifeste la plupart du temps par un plantage) dans un temps plus ou moins court.

Mon expérience du fuzzing

J'avais lu beaucoup de rapports de fuzzing montrant clairement de grosses faiblesses dans quasiment l'ensemble des logiciels testés. Mais je n'y croyais qu'à moitié, il fallait que je le vois de mes propres yeux. J'ai alors écrit un programme de fuzzing pour mon projet Hachoir. Durant deux semaines j'ai continuellement corrigé des bugs plus ou moins critiques. Comme quoi, la technique fonctionne très bien !

J'ai ensuite adapté mon programme de fuzzing pour tester d'autres applications. J'ai testé sur la suite Image Magick (manipulation de photos)... que je suis arrivé très rapidement à faire planter. J'ai isolé deux cas critiques : pour une image XCF de 80 Ko, Image Magick allouait 1 Go de mémoire (ce qui est énorme), et pour une image TGA, Image Magick consommait toute la puissance du processeur (100% du CPU) durant plusieurs minutes (je n'ai pas eu la patience de mesurer le temps exact). J'ai tenté de rapporter le bug mais je n'ai eu aucun retour.

Je me suis alors senti poussé des ailes et je me suis senti invinsible :-) Tant qu'à faire, allons tester un élément de sécurité ! J'ai choisi au pif l'anti-virus ClamAV... que j'ai réussi assez rapidement à mettre à genoux. Un document Word forgé prend 2 Go de disque dur et l'ensemble du processeur pendant plusieurs minutes. J'ai rapporté le bug qui a été classé comme critique et sera corrigé dans la prochaine version.

Écriture du programme de fuzzing

En pratique, pour Hachoir, Image Magick et ClamAV : je suis parti de fichiers valides (le format dépendant de l'outil testé) que j'ai ensuite tronqué et/ou j'y ai inséré des octets aléatoires. Je passe alors ce fichier forgé au programme testé. Cette algorithme est celui du programme « mangle.c » écrit par le belge Ilja van Sprundel que j'ai réécrit en Python. J'ai ensuite ajouté d'autres opérations comme modifier plusieurs octets à la fois, incrémenter/décrémenter un octet, insérer des valeurs spéciales, etc.

Ce qui me fait peur, c'est que globlament mon programme de test reste extrênement simple et pourtant j'arrive à faire planter très rapidement (moins de 5 minutes) tous les programmes que j'ai testés. Je n'ose même pas imaginer ce qu'on pourrait découvrir avec des programmes beaucoup plus intelligents. Et justement, l'été dernier des conférences ont présenté des logiciels de fuzzing utilisant des algorithmes génétiques ainsi qu'une grammaire dédiée au fuzzing. Le but étant, en gros, d'arriver le plus profondément possible dans le programme cible. Ils utilisent un débogueur dédié ainsi qu'un outil permettant de mesurer la couverture du code (quantité de code exécuté dans le programme cible).

Je pense qu'en couplant un fuzzing avec un outil comme Valgrind, on pourrait créer des outils beaucoup plus intelligents car on connaitrait la couverture du code mais également les erreurs d'accès mémoire.

Le fuzzing étant assez nouveau pour moi, je ne saurai conseiller un site web en particulier. En attendant, suivez les liens donnés sur la page Fuzzing de mon wiki. Je la ferai vivre au fur et à mesure des mes recherches.