Hello,
 
Je souhaitez savoir s'il y en avait qui avait une experience concernant le fuzzing, et quels outils etait utilisé, du au commercial, sur de l'open source comme sur Windows et compagnie ?
 
Merci !

Au cas ou, je poste ici en quoi cela consiste
 
http://fr.wikipedia.org/wiki/Fuzzing

up (bon daccord ca fait un peu tot lol)

D'après wikipedia, ça date des années 90 et semble bien dépassé. En effet, une des techniques actuelles pour corriger les failles est de réaliser des tests unitaires lors du développement et c'est certainement plus efficace car plus poussé

C'est tout sauf dépassé, le fuzzing est une des méthodes les plus utilisées et les plus puissantes pour découvrir des failles dans une application, la sienne ou celle de quelqu'un d'autre (recherche en sécurité)

Des tests unitaires ne testent que ce qu'on pense à tester, et ça ne teste pas une stack complète. Des tests unitaires prouvent qu'une unité de calcul semble avoir un résultat correct pour un set d'entrées données, c'est incapable de prouver qu'une unité de calcul est correcte dans l'absolu.
 
Accessoirement, certaines communautés de programmeurs (c'est à ma connaissance originaire de la communauté Haskell) ont hybridé les notions de fuzzing et de unit testing en créant des générateurs de testcases aléatoires:
 
QuickCheck (le générateur originel, à ma connaissance) et SmallCheck en Haskell, ScalaCheck en Scala, ErlangQC en Erlang, RushCheck en Ruby, ClickCheck et PeckCheck pour Common Lisp et Python.
 
Aucune des implémentations inspirées n'est complète par rapport au QuickCheck Haskell (probablement parce que QC utilise fortement le type system haskell), ceux qui en viennent le plus près sont probablement Scalacheck (parce que le typesys scala est également très fort et statique) et Quviq QuickCheck pour Erlang parce que c'est un produit commercial

Je remerci vivement Masklinn pour ces informations.
 
Cela me donne une base pour contnuer, mais je sent que la route et longue ;-)

Je cherche une pesonne le pratiquant pour lui poser certaines questions techniques, je cherche a comprendre ce domaine mais il manque d'infos sur la toile...

Il y a aussi zzuf
http://sam.zoy.org/zzuf/

Ce site je lavais trouvé mais dessus pas de tuto, cette personne est francaise ?

apres verif oui elle est francaise, je vais la contacter

Merci pour l'info

 
tout à fait malheureusement, le pouf de la première Ariane 5 en est un excellent exemple.
 
 

bjone > Même avec du fuzzing, le "pouf" de la première Ariane 5 aurait eu lieux vu que ça n'était pas du à un problème de test unitaire mal conçu mais à un trop gros écart entre les simulations et la réalité : la fusée à subit une accélération bien plus importante que prévus ce qui a provoqué des erreurs de données (donné stocké sur moins de bit que ce qu'il aurait fallut)
Même si tes composants sont parfait, si tu leur fournis des données erronées, tu auras peu de chance d'avoir un résultat correct et là dessus je te rejoint : les test unitaires ne permettent pas de détecter les erreurs survenant a l'extérieur de l'élément testé.
 
En fait, dans le cas d'une fusée comme Ariane 5, si des test de fuzzing ont lieux et que le résultat de ces tests indiquent que le programme va se tromper si la fusée subit une accélération 5 fois plus importante que l'accélération maximale qu'elle est censé subir, les techniciens vont considérer que le programme est valide. Si derrière, la fusée subit vraiment une telle accélération, alors le défaut ne sera pas du aux tests (unitaire ou de fuzzing) mais à des erreurs dans les simulations qui avaient permis de calculer l'accélération maximale de l'appareil.

C'était pas un problème de prévision, c'était un problème d'utilisation du software Ariane4 sans prendre en compte certaines modifications de contraintes (dont la différence d'accélération) et en ayant désactivé l'interrupt handler (normalement ce genre d'erreur d'overflow stupides, ça ne passe pas en ada).

Masklinn > Autant pour moi alors, mais si c'était du entre autre à la désactivation de l' "interrupt handler", même avec du fuzzing, ils ne se seraient rendus compte de rien j'imagine vu que le programme n'aurait pas planté.
Je me trompe?

Ouaip, le programme aurant planté (comme il l'a fait) puisque le fuzzing peut se faire sur le programme complet (c'est habituellement comme ça qu'il est fait: le logiciel est une boite noire, on balance des données de fuzzing dedans et on regarde comment il réagit).
 
L'interrupt handler est là pour intercepter ce genre de problèmes (hardware exception causée par un overflow, ici) et potentiellement les traiter.
 
Je te conseille de lire l'article sur la wikipedia sur le sujet (http://en.wikipedia.org/wiki/Ariane_5_Flight_501) il n'est pas trop dense et donne déjà une vue d'ensemble du truc, et il y a des liens vers des articles intéressants (et même un bout de code expliqué si tu lis l'allemand)