Blog Haypo

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 5 juillet 2007

Fuzzing, deux mois plus tard

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.

Schéma de la hiérarchie des autotools

Histoire d'affronter ma phobie (irrationnelle ?) des autotools(*), j'ai décidé de documenter un peu cette suite d'outils dans mon wiki ainsi qu'en dessinant une schéma présentant l'organisation des différents fichiers et programmes (schéma ci-dessous).

(cliquez sur l'image pour la voir en taille réelle)

Le schéma comporte sûrement des imprécisions voir même des erreurs. Un ami m'a signalé par exemple que je n'ai pas noté l'outil autoscan. Je ne veux pas l'ajouter sous peine de surcharger ce schéma déjà énorme. En tout cas, je me suis bien amusé avec Dia (outil de dessin vectoriel, spécialisé dans les diagrammes). En jouant sur les couleurs, on arrive à un résultat que je trouve pas dégueux.

J'espère que ce schéma servira à d'autres pour pénétrer l'univers des autotools :-)

Note (*) : Les autotools sont une suite d'outils servant à construire un logiciel à partir de son code source (le « compiler » en argot informatique).