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.
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
- Fusil le fuzzer (59 clics)
- Conférence Fusil au FOSDEM 2009 (9 clics)
- Listes des bugs trouvés par Fusil (16 clics)
- DLFP: Fusillez vos applications avec Fusil 0.6 (déc. 2007) (34 clics)
- MISC : dossier sur le Fuzzing (41 clics)
# Un indispensable du cycle de développement
Posté par Carl Chenet (site web personnel) . Évalué à 1.
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 Victor STINNER (site web personnel) . Évalué à 8.
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 mac_is_mac (site web personnel) . Évalué à -5.
[^] # Re: Un indispensable du cycle de développement
Posté par pasBill pasGates . Évalué à 4.
[^] # Re: Un indispensable du cycle de développement
Posté par snt . Évalué à 10.
>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 Carl Chenet (site web personnel) . Évalué à -4.
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 Guillaume Denry (site web personnel) . Évalué à 8.
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 Mjules (site web personnel) . Évalué à 1.
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 Zenitram (site web personnel) . Évalué à 2.
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 Kerro . Évalué à 2.
mes fournisseurs étaient très professionnels, ont toujours corrigé les bugs soumis par mes utilisateursMauvaise 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 Carl Chenet (site web personnel) . Évalué à 4.
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 pasBill pasGates . Évalué à 1.
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 Guillaume Denry (site web personnel) . Évalué à 3.
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 pasBill pasGates . Évalué à 5.
- 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 BAud (site web personnel) . Évalué à 3.
[^] # Re: Un indispensable du cycle de développement
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Un indispensable du cycle de développement
Posté par patrick_g (site web personnel) . Évalué à 5.
[^] # Re: Un indispensable du cycle de développement
Posté par pasBill pasGates . Évalué à 2.
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
[^] # Re: Un indispensable du cycle de développement
Posté par ashram4 . Évalué à 3.
histoire de ne pas me laisser sur ma fin tu pourrais développer le sujet. Dans quelle presse? sur quel sujet? un exemple?
L'environnement : Je bosses regulierement avec des tetes genre Matt Miller, Dan Kaminsky, Michael Eddington, ...
Je ne sais pas qui est Matt Miller. Michael Eddington est un officier de sécurité qui abandonné son poste dans Star Trek. Heureusement j'ai trouvé des infos sur Dan Kaminsky. Je ne suis pas développeur de renom ni (malheureusement) de grand talent mais dois-je m'inquiéter de ne pas connaitre ces personnes?
[^] # Re: Un indispensable du cycle de développement
Posté par ashram4 . Évalué à 2.
[^] # Re: Un indispensable du cycle de développement
Posté par pasBill pasGates . Évalué à 2.
http://www.eweek.com/c/a/Security/Microsoft-Patch-Tuesday-Fi(...)
http://blogs.pcmag.com/securitywatch/2008/12/8_patches_from_(...)
etc...
Je ne sais pas qui est Matt Miller. Michael Eddington est un officier de sécurité qui abandonné son poste dans Star Trek. Heureusement j'ai trouvé des infos sur Dan Kaminsky. Je ne suis pas développeur de renom ni (malheureusement) de grand talent mais dois-je m'inquiéter de ne pas connaitre ces personnes?
Matt Miller (aka Skape) : http://www.hick.org/~mmiller/
Michael Eddington : http://phed.org/ & http://peachfuzzer.com/
Ils sont assez connus dans le monde de la securite, mais vu ce qu'ils font, il est assez normal qu'en dehors de ce monde ils ne le soient pas trop
[^] # Re: Un indispensable du cycle de développement
Posté par ashram4 . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.