Publication de Fusil le fuzzer 1.2

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
12
21
fév.
2009
Python
Fusil est à la fois une bibliothèque de fuzzing et une vingtaine de fuzzers (Gstreamer, ClamAV, Python, etc.). Bien qu'il vise d'abord les applications Linux en ligne de commande, on peut l'utiliser pour tester des applications graphiques comme Firefox ou VLC en scriptant ces applications. Le fuzzing est une technique de recherche de bogues utilisant l'injection de fautes pour évaluer et améliorer la stabilité d'un logiciel. Un bogue pouvant parfois aboutir à une faille de sécurité, cette technique sert également à rechercher des vulnérabilités.

Avec la version 1.2, la documentation comprend désormais un manuel utilisateur et un tutoriel pour écrire un fuzzer. Fusil indique maintenant des informations sur un crash dans le nom du dossier qui le contient. On peut donc rapidement isoler les doublons et analyser les crashs les plus intéressants en premier. Enfin, la compatibilité avec Python 3.0 a été améliorée. Fusil est écrit en Python 2.5 et fonctionne sous Linux, BSD, Mac OS X et Windows. Le projet est distribué sous licence GPLv2. Il existe des paquets pour Debian, Ubuntu, Mandriva, OpenEmbedded, Arch Linux, Gentoo, ainsi qu'un MacPort. Pour les curieux, il existe aussi un script de conversion pour Python 3.0. Liste des fuzzers :
  • Applications : ClamAV, Firefox, Gstreamer, mplayer, VLC, Image Magick ;
  • Bibliothèques : gettext, poppler, printf() ;
  • Langages de programmation : PHP, Python.
Lors d'un crash, Fusil crée un dossier où sont stockés les logs du fuzzer, la sortie standard du programme et les fichiers générés pour le test. Un script (replay.py) est généré pour pouvoir rejouer le crash dans un débogueur (gdb ou Valgrind) et donc isoler plus précisément l'origine du bogue.

Depuis la version 1.0, Fusil exécute les processus fils sous un utilisateur dédié (fusil) pour éviter que le programme testé ne supprime vos fichiers personnels ou tue des processus aléatoires. La mémoire, le temps d'exécution et le nombre de processus sont également limités pour éviter d'impacter les performances globales de l'ordinateur. Une campagne de fuzzing peut donc être lancée une nuit entière sans risque, Fusil étant entièrement autonome.

Le fonctionnement de Fusil a été présenté à plusieurs reprises : SSTIC 2007 (lors d'une rump session), RMLL 2008 et FOSDEM 2009 (voir le diaporama, l'enregistrement vidéo est à venir). Deux articles ont également été publiés dans les magazines MISC n°36 et n°39.

Aller plus loin

  • # Un indispensable du cycle de développement

    Posté par  (site web personnel) . Évalué à 1.

    Pour moi Fusil mais le fuzzing en général devrait être incorporé à tous les projets de développement.

    Pouvoir anticiper sur la remontée de bugs en les cherchant soi-même de manière automatisée devrait être une pratique comprise et pratiquée par tous les développeurs de logiciels libres (je ne parle pas des développeurs de logiciels privateurs qui préfèrent attendre que le client remonte un bug qu'ils vont s'empresser d'appeler une "nouvelle fonctionnalité manquante" ce qui va leur permettre de sortir une nouvelle version *payante*).

    Et merci à titre perso car j'utilise fusil pour mes projets et ça rend bien des services.

    • [^] # Re: Un indispensable du cycle de développement

      Posté par  (site web personnel) . Évalué à 8.

      Certains éditeurs comme Google et Microsoft ont intégré le fuzzing à leur processus de développement (au lieu de faire le fuzzing à la fin du développement ou après la sortie du produit). pasBill pasGates qui travaille pour Microsoft en parlait dans un de mes précédents journal sur Fusil :
      http://linuxfr.org/comments/885931.html#885931

      Google a publié un fuzzer sous GPL, Flayer :
      http://code.google.com/p/flayer/

      Je ne sais pas si Google et Microsoft utilisent le fuzzing dans tous les développements, mais ce qui est sûr, c'est qu'ils en font. Disons qu'ils sont assez exposés aux pirates...

      • [^] # Re: Un indispensable du cycle de développement

        Posté par  (site web personnel) . Évalué à -5.

        Et bien sûr, chez Microsoft, les meilleurs bugs sont gardés dans la version finale...

      • [^] # Re: Un indispensable du cycle de développement

        Posté par  . Évalué à 4.

        Tous les developpements ici doivent suivre la SDL (security development lifecycle) et celle-ci definit les cas dans lesquels du fuzzing est necessaire ce qui d'habitude revient a : si ton interface peut recevoir les donnees d'un utilisateur autre que celui sous lequel il tourne(meme indirectement, quoique on a un concept de "nettoyage des donnees" par les interface intermediaires entre le composant et l'utilisateur qui definit ou cela s'arrete), c'est necessaire.

    • [^] # Re: Un indispensable du cycle de développement

      Posté par  . Évalué à 10.

      >je ne parle pas des développeurs de logiciels privateurs qui préfèrent
      >attendre que le client remonte un bug qu'ils vont s'empresser
      >d'appeler une "nouvelle fonctionnalité manquante" ce qui va leur
      >permettre de sortir une nouvelle version *payante*

      Qu'ils sont vilains ces développeurs de logiciels non libres ! Et malhonnêtes et incompétents et feignants.
      Et schizophrènes aussi, parce que certains d'entre eux contribuent aussi à des logiciels libres. Ils doivent avoir une double personnalité : le jour ils deviennent mauvais et ils se moquent de leur clients, puis à la nuit tombée ils se soucient de leurs utilisateurs.
      J'ai du me planter dans mes signets, j'ai pas vu que j'étais sur préjugéspourrisfr.org.

      • [^] # Re: Un indispensable du cycle de développement

        Posté par  (site web personnel) . Évalué à -4.

        Parce que c'est un préjugé de dire que le business-model des boîtes de développement repose sur le fait de vendre une nouvelle version et que le fait que la nouvelle version apporte vraiment quelque chose n'a que peu d'importance ?

        C'est aussi un préjugé de dire que les seuls bugs qui existent pour l'immense majorité des boîtes de développement de logiciels commerciaux, c'est la liste des bugs critiques et qu'ils n'ont souvent pas les moyens de mettre quelqu'un sur le test et la consolidation de l'existant et que c'est l'utilisateur final le bêta-testeur ?

        Et qu'un bon développeur de logiciels libres avec des idées modernes de développement (tests unitaires, fuzzing) soit contraint de bâcler son travail par des chefs de projet peu soucieux de qualité à son travail, il n'y a que toi pour l'appeler schizophrène, même si le résultat de son travail reste un logiciel privateur.

        • [^] # Re: Un indispensable du cycle de développement

          Posté par  (site web personnel) . Évalué à 8.

          Parce que c'est un préjugé de dire que le business-model des boîtes de développement repose sur le fait de vendre une nouvelle version et que le fait que la nouvelle version apporte vraiment quelque chose n'a que peu d'importance ?

          Oui. Tu bosses dans quelle boite pour que je n'achète pas leurs produits ?


          C'est aussi un préjugé de dire que les seuls bugs qui existent pour l'immense majorité des boîtes de développement de logiciels commerciaux, c'est la liste des bugs critiques et qu'ils n'ont souvent pas les moyens de mettre quelqu'un sur le test et la consolidation de l'existant et que c'est l'utilisateur final le bêta-testeur ?


          Non mais au secours ! T'es quoi ? étudiant ? Tu n'as vraiment pas l'air de savoir comment ça fonctionne dans une boite d'édition de softwares.
          J'ai d'ailleurs tendance à penser le contraire ! dans le libre, on s'attache plus à développer ce qui nous fait plaisir au détriment parfois de la qualité. Sur ton temps libre, t'as pas forcément envie de débourrer une appli sur une ancienne version de ton soft alors que tu bosses sur la nouvelle, par exemple. Ce qui me semble d'ailleurs logique. Si des gens veulent une ancienne version débourrée, ils n'ont qu'à soit me payer, soit mettre eux-même la main à la patte.
          Dans ma boite, tu peux pas te permettre ça, des gens ont payé un support logiciel et s'attendent à ce que tu corriges les bugs dans la version du produit qu'ils ont payé.
          Bon, par "déformation professionnelle" c'est aussi un peu ma philosophie quand je développe du libre sur mes soirées et WE, du coup...

          Ta dichotomie en ce qui concerne la qualité des logiciels privateurs d'un côté et des logiciels libres de l'autre me fait vraiment penser à une extrapolation pleine de préjugés. C'est d'autant plus choquant quand on connait vraiment les deux mondes.

          • [^] # Re: Un indispensable du cycle de développement

            Posté par  (site web personnel) . Évalué à 1.

            Je ne bosse dans aucune boite mais j'utilise régulièrement des logiciels dit métiers.

            Et bien, je ne dois pas avoir de chance parce que tous les softs métiers que j'ai eu à utiliser avaient ce genre de problème : mal intégrés, buggés jusqu'à en être limite utilisable, très chers, mises à jours tout les 36 du mois et qui ne corrigent pas les bugs les plus critiques

            Évidemment, que des logiciels privateurs (dont un viole la licence de gettext tant qu'à faire) mais ce n'est pas très représentatif.

            Bref, tout ça pour dire que tes utilisateurs ont de la chance que vous vous intéressiez à la qualité. C'est pas le cas de tout le monde.

            • [^] # Re: Un indispensable du cycle de développement

              Posté par  (site web personnel) . Évalué à 2.

              Et bien, je ne dois pas avoir de chance parce que tous les softs métiers que j'ai eu à utiliser avaient ce genre de problème

              Tu n'as pas de chance, c'est tout, et ça n'en fait pas une généralité : j'ai eu l'occasion de gérer les achats et le suivi de logiciels métier (et proprio), et mes fournisseurs étaient très professionnels, ont toujours corrigé les bugs soumis par mes utilisateurs. Seules les nouveautés étaient facturées par une nouvelle version (avec remise si on avait la version précédente, bref prix de mise à jour).
              Bon, après 1 an, on payait la maintenance corrective, mais je trouve ça normal (dans le libre, on paye aussi si on veut une maintenance contractuelle...)

              De plus, tu peux le voir avec l'OS majoritaire : tu achètes une fois, et ça fait maintenant 7 ans que son vendeur fournit des mise à jour gratuites (c'est seulement si tu veux une évolution que tu payes).

              Ton avis sur les logiciels proprios est donc complètement subjective, orienté.

              • [^] # Re: Un indispensable du cycle de développement

                Posté par  . Évalué à 2.

                mes fournisseurs étaient très professionnels, ont toujours corrigé les bugs soumis par mes utilisateurs
                Mauvaise fois inside, hum ? :-)
                Que ce soient les ténors du marché ou les actueurs secondaires, il est extrèmement rare que les logiciels "métier" soient convenables. Pour ma part les moins mauvais que j'ai vu fonctionnent parceque les utilisateurs savent qu'il ne faut pas utiliser telle fonction, et que pour obtenir tel résultat il faut prendre un chemin détourné.
                Ca vaut autant pour CEGID/SAGE/ADONIX que pour des logiciels parfaitement inconnus. Je ne parle même pas de SAP puisque là, les bugs sont le fruit de l'intégrateur. Et en général c'est pire que moche.

                Ton avis sur les logiciels proprios est donc complètement subjective, orienté.
                Ha ok, c'est un jour sans. Rien de grave, tout reviendra en ordre après une bonne nuit de sommeil. :-)

          • [^] # Re: Un indispensable du cycle de développement

            Posté par  (site web personnel) . Évalué à 4.

            Ah oui d'ailleurs Microsoft corrige tous les bugs qu'on lui signale, ils sont efficaces là dessus. Pareil pour SAP et je te parle pas des autres gros à qui tu renvoies un rapport de bugs et dont tu peux considérer avoir de la chance si tu as un retour.

            Sans parler des atteintes à la liberté d'utilisation caractéristique du type "oui faut utiliser notre soft sur tel os puis telle version de java puis telle lib machin et boire telle marque de café sinon vous êtes hors charte d'utilisation et vous n'aurez pas de support".

            Je suis le premier à être critique sur la qualité des logiciels libres mais pitié, faut sortir la tête de l'eau, la qualité des logiciels privateurs tu l'évalues comment ? Sûrement pas en lisant le code source ...

            T'as deux/trois boîtes de dév. avec qui tu travailles qui sont réactives parce qu'elles sont dans un marché de niche et qu'elles te fournissent une appli métier ? Cool, mais ça ne résume pas le monde du logiciel privateur, celui des gros acteurs du marché et des gros contrats de support sans lesquels c'est même pas la peine de contacter le support. Désolé de te sortir de ton contexte limité et de ton jugement biaisé par ton expérience professionnelle/personnelle.



            • [^] # Re: Un indispensable du cycle de développement

              Posté par  . Évalué à 1.

              Ah oui d'ailleurs Microsoft corrige tous les bugs qu'on lui signale, ils sont efficaces là dessus. Pareil pour SAP et je te parle pas des autres gros à qui tu renvoies un rapport de bugs et dont tu peux considérer avoir de la chance si tu as un retour.

              Les failles oui si on les considere comme des failles valides, et vu notre reputation dans le monde de la securite(a ne pas confondre avec le monde des fanboys Linux, je parles des gens qui savent ce qu'est une faille), faut croire qu'on fait un bon boulot.

              Sinon niveau bugs "non-securite", tu penses quoi des bugs qui datent de plus d'un an dans les bugzillas de Mozilla, OOo, ... ?

              Sans parler des atteintes à la liberté d'utilisation caractéristique du type "oui faut utiliser notre soft sur tel os puis telle version de java puis telle lib machin et boire telle marque de café sinon vous êtes hors charte d'utilisation et vous n'aurez pas de support".

              T'as raison c'est scandaleux, tu devrais penser a te plaindre a Redhat.
              Sinon, le support n'a rien a voir avec la liberte d'utilisation hein...

              T'as deux/trois boîtes de dév. avec qui tu travailles qui sont réactives parce qu'elles sont dans un marché de niche et qu'elles te fournissent une appli métier ? Cool, mais ça ne résume pas le monde du logiciel privateur, celui des gros acteurs du marché et des gros contrats de support sans lesquels c'est même pas la peine de contacter le support. Désolé de te sortir de ton contexte limité et de ton jugement biaisé par ton expérience professionnelle/personnelle.

              Si on regarde la plus grosse boite de logiciels "privateurs" de la planete, elle fait un bien meilleur boulot qu'a peu pres n'importe qui d'autre dans le domaine, et elle depense certainement bcp plus sur la securite de ses softs que n'importe qui d'autre.

            • [^] # Re: Un indispensable du cycle de développement

              Posté par  (site web personnel) . Évalué à 3.

              Tu mélanges tout. Tu parlais de qualité des logiciels closed source VS logiciels opensource et maintenant tu viens nous causer du support technique.
              Je te dis juste que d'affirmer que le closed source bénéficie d'un processus qualité moindre que celui des logiciels opensource est une connerie monumentale. Ça n'a pas de sens de placer la dichotomie à cet endroit.
              En ce qui concerne le support technique, j'ai aussi un embryon d'avis sur la question mais je doute qu'il te plaise également car il ne coïnciderait probablement pas avec une vision manichéenne du "privateur pourri".

        • [^] # Re: Un indispensable du cycle de développement

          Posté par  . Évalué à 5.

          Rigolons un peu mon cher, prends tous les softs qu'il y a dans Debian (ou Fedora, ou autre)

          - Combien on eu un threat model developpe ?
          - Combien ont eu des code reviews orientees securite faites ?
          - Combien ont ete testees par un fuzzer efficace ?
          - Combien ont eu leur design revu par un groupe oriente securite ?

          Eh oui, on se rend tres tres vite compte qu'en fin de compte, les LL c'est le meme topo que tous les autres logiciels a ce niveau la : les plus gros font un boulot decent car ils se sont rendu compte que sans ca les alertes de securite affluent, les autres sont tous a la meme enseigne: tres peu voire rien, soit car ils ne savent pas que ca existe, soit parce qu'ils s'en foutent, soit parce qu'ils n'en ont pas les moyens(humains, financiers, ...).

          • [^] # Re: Un indispensable du cycle de développement

            Posté par  (site web personnel) . Évalué à 3.

            tu viens aider quand ? :D

            • [^] # Re: Un indispensable du cycle de développement

              Posté par  . Évalué à 1.

              Le jour ou je commencerais a trouver ca plus interessant que le job que j'ai, c'est pas le cas pour l'instant.

              • [^] # Re: Un indispensable du cycle de développement

                Posté par  (site web personnel) . Évalué à 5.

                Intéressant financièrement ou intéressant intellectuellement ou autre chose ?

                • [^] # Re: Un indispensable du cycle de développement

                  Posté par  . Évalué à 2.

                  Le salaire n'est pas specifiquement le probleme, j'imagines que je gagnerais a peu pres la meme chose si je bossais pour IBM, voire Redhat ou autre grosse boite, et pas mal plus si je devenais consultant securite.

                  Il y a plusieurs cotes :
                  a) Le cote "mon job a un impact" : je vois les resultats de mon boulot dans la presse tous les mois (ca amene aussi son stress, si je merdes, c'est aussi dans la presse...), c'est plutot gratifiant de savoir que ce que tu fais affecte des centaines de millions de gens d'une maniere positive.

                  b) L'environnement : Je bosses regulierement avec des tetes genre Matt Miller, Dan Kaminsky, Michael Eddington, ...

                  c) Possibilites : J'ai acces a des outils ici qui sont sans commune mesure avec ce qui se trouve ailleurs(petit exemple: ftp://ftp.research.microsoft.com/pub/tr/TR-2007-58.pdf )

                  d) Liberte : J'ai totale liberte de faire a peu pres ce que je veux dans ma position actuelle, mon manager me fait totalement confiance et suit a peu pres tout ce que je propose, et je peux reutiliser tout ce qui existe en interne pour developper de nouveaux outils(une vraie mine d'or), pour que je change de job (y compris a l'interieur de MS), il faudrait que je retrouves cette liberte totale ce qui risque d'etre dur

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.