Wikipedia donne pour le fuzzing, la définition suivante (https://fr.wikipedia.org/wiki/Fuzzing) :
Le fuzzing (ou test à données aléatoires) est une technique pour tester des logiciels. L'idée est d'injecter des données aléatoires dans les entrées d'un programme. Si le programme échoue (par exemple en plantant ou en générant une erreur), alors il y a des défauts à corriger. Exemples de points d'entrée d'un programme :
- Fichiers
- Périphériques (clavier, souris, etc.)
- Variables d'environnement
- Réseau
- Limitation des ressources (mémoire, disque dur, temps CPU, etc.)
- etc.
Cette définition montre bien, que la difficulté est de bien générer des jeux de données (aléatoires ou semi aléatoire) permettant de mettre à défaut son logiciel.
Jusqu'à récemment, il existait deux catégories d'outils de fuzzing :
- ceux utilisant la force brute
- et ceux partant d'un profil de test bien particulier
Le problème des outils utilisant la force brute est qu'ils ne permettent pas de trouver des cas complexes de crash dans un temps fini.
Le problème des outils utilisant des profils de test est qu'ils nécessitent une connaissance approfondie du logiciel à tester et généralement permettent de ne trouver que les types d'erreurs que l'on souhaite chercher.
Comme le montre cet article http://lwn.net/Articles/657959/, depuis septembre 2014 et la découverte du problème Shellshock dans bash (problème existant depuis 25 ans ! avec la livraison de la version 1.03 de bash en 1989), un chercheur en sécurité de chez Google a trouvé un nouvelle stratégie pour effectuer du fuzzing en force brute mais de façon plus efficace.
E il a développé l'outil American Fuzzy Lop (en C), qui a permis de :
- découvrir le Shellshock de bash (une faille de 25 ans),
- découvrir des denial-of-service sur le serveur DNS Bind
- de redécouvrir la célèbre faille Heartbleed sur OpenSSL (attaque réputé complexe et qu'il a trouvé en seulement 6 heures de fuzzing)
- et d'autres
Actuellement, il existe des déclinaisons de cet outil pour les langages suivants :
- Go (https://github.com/dvyukov/go-fuzz) (cf. ci-desous)
- Python (https://bitbucket.org/jwilk/python-afl)
- Rust (https://github.com/frewsxcv/afl.rs)
- GCJ Java(https://gcc.gnu.org/java/)
Ces outils fonctionnent de la façon suivante, ils vont :
- instrumentaliser votre logiciel à tester afin "d'observer ses réactions"
- injecter des trames aléatoires basées sur des corpus utilisés lors de vos tests unitaires par exemple
- s'il détecte une nouveau de chemin d'exécution de votre logiciel, il va enrichir le corpus (initialement composé de vos tests unitaire) et se basé sur cette entrée pour générer de nouvelles trames aléatoires.
- s'il identifie un crash/exception/panic/boucle infinie/fuite mémoire, il trace l'entrée et l'éventuelle stack-trace pour correction ultérieure.
# Property-based testing
Posté par flan (site web personnel) . Évalué à 4.
Je trouve que l'approche du fuzzing ressemble pas mal au Property-based testing (on définit une propriété que doit respecter une fonction, et on teste des entrées plus ou moins aléatoires sur la fonction. Le fuzzing ici décrit fonctionne sur le programme complet, alors que le property based testing teste surtout les fonctions individuellement.
# Rien de nouveau
Posté par pasBill pasGates . Évalué à 8.
Cette approche est une forme primitive de résolution de contraintes appliquée aux tests sécurité. Quelque chose que Microsoft fait depuis presque 10 ans avec SAGE :
http://research.microsoft.com/en-us/um/people/pg/public_psfiles/ndss2008.pdf
[^] # Re: Rien de nouveau
Posté par barmic . Évalué à 8.
C'est une façon de dire que ce n'est pas si efficace que ça ? ;-p
Je te taquine, mais c'est quoi la « résolution de contraintes » ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de nouveau
Posté par woffer 🐧 . Évalué à 5.
Je ne connais pas SAGE de Microsoft.
Par contre, je peux te dire que la stratégie de fuzzing détaillée dans l'article lwn est très efficace.
J'ai pu la mettre en pratique sur un stack réseau interne écrite en Go, et go-fuzz m'a trouvé tout un tas de d'accès en dehors des limites de divers tableaux et surtout une belle boucle infinie avec une belle fuite mémoire en prime.
[^] # Re: Rien de nouveau
Posté par flagos . Évalué à 5. Dernière modification le 28 octobre 2015 à 15:39.
La résolution de contraintes, ca consiste à définir:
- un certain nombre de paramètres et leur types (par exemple, définir qu'un "id" est un uint)
- les contraintes intrinsèques de ces paramètres ( un "id" est compris entre 0 et 15)
- les contraintes externes ( si le paramètre "anonymous_flag" est a 1, alors "id" vaut 15)
Ca c'est pour définir les règles générales de ton jeu de tests. Tu peux également rajouter des contraintes en dynamique, juste pour un test en particulier, par exemple:
- pour ce test, "id" vaut 5.
Ton test a alors perdu en aléatoire puisque "id" est contraint mais pour autant les autres paramètres non liés sont tout autant aléatoires: c'est ce qu'on appelle un test semi-dirigé.
Et donc, pour répondre à ta question, la résolution de contraintes, c'est un logiciel (ou un algorithme) qui va prendre en considération toutes ces contraintes et te donner une dataset qui répond à ce que tu lui as demandé, te permettant ainsi de générer une database de tests aux petits oignons.
A ma connaissance, un des premiers logiciels (sinon le premier ?) à avoir apporté la résolution de contraintes pour un environnement de test est Specman de Cadence (désolé pbpg, c'est pas MS), qui a été massivement utilisé dans l'industrie de la micro-électronique.
https://en.wikipedia.org/wiki/E_(verification_language)
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 10.
Ca revient à cela :
SAGE va passer un fichier de base à ton soft(en réalité il y a un corpus, de manière à accélérer SAGE en utilisant plusieurs fichiers qui ensemble couvrent de base la majorité des branches). Il va regarder toutes les instructions que ton code éxécute pendant le parsing du fichier. Il va ensuite regarder quelles sont les branches de code qui pourraient être prises et qui ne l'ont pas été. Il va alors créer des fonctions mathématiques pour résoudre le problème suivant :
- a quoi devrait ressembler le fichier pour que la branche X soit éxécutée ?
Il va ensuite utiliser un solveur (Z3 de MS Research) pour résoudre cela, créer le fichier, et le repasser dans le soft.
Il fait ça constamment, pour au final éxécuter toutes les branches de ton code (idéalement, en asymptotique).
La différence avec AFL :
SAGE a des limites : genre si t'as une one-way hash dans ton format, il ne va évidemment pas pouvoir faire une résolution pour trouver une valeur de hash correcte, et si il y a de la compression, cela ralentit SAGE de manière significative. Mais c'est de loin, très loin, le système de fuzzing le plus efficace que j'ai jamais vu( au point ou je préféres ne pas utiliser le mot fuzzing pour SAGE, parce que justement ce n'est pas aléatoire du tout), et j'ai passé la majorité de ma carrière sur ce sujet précis à MS.
[^] # Re: Rien de nouveau
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Quelques infos collectées autour de SAGE :
[^] # Re: Rien de nouveau
Posté par octane . Évalué à 3.
oui, mais non. Sage n'a rien à voir.
Tout d'abord, Sage est closed source, et on en sait que ce que les gens veulent bien en dire…
Ensuite, Sage fait de la résolution de contraintes, ce qui implique un solveur (Z3). Et généralement, les papiers qui en parlent disent que la résolution de contraintes sur un projet trop gros a tendance à exploser et donc on limite le scope à un sous ensemble, ou une sous fonction, ce qui limite beaucoup la chance de trouver des bugs.
Dans le monde réél, je ne crois pas avoir lu: "This bug has been found with Sage". Par contre, j'ai beaucoup lu "Alors le bug machin qui a été trouvé, on a essayé de le reproduire avec Sage, on a monitoré la fonction coupable et on a réussi à retrouver la faille, regardez comme Sage c'est génial et ça écrase les fuzzers".
Pour résumer, on a Sage qui est apparemment génial, qui demande un bac+18 pour être mis en oeuvre, sur un sous-ensemble réduit de fonctionnalités.
De l'autre, on a afl. On prend un prog, on le recompile (ou pas), on le balance à afl même si on ne connait rien à son format d'entrée, on attend un peu et il trouve des bugs, des vrais, et il en trouve vite, et beaucoup.
On pourrait croire que je suis anti-Sage, mais non, je veux juste dire que afl et Sage n'ont rien à voir. Afl, c'est bon, c'est simple, ça augmente réellement la qualité de vos programmes.
Sage, bah tant que ça restera cantonné chez MS research, ça fournira des papiers enthousiastes, ça n'augmentera pas la sécurité de vos programmes.
Le papier que tu cites en commentaire, si on le prends page 2:
void top(char input[4]) {
int cnt=0;
if (input[0] == ’b’) cnt++;
if (input[1] == ’a’) cnt++;
if (input[2] == ’d’) cnt++;
if (input[3] == ’!’) cnt++;
if (cnt >= 3) abort(); // error
}
Bah si, afl le trouve, et très vite même. Sage le trouve encore plus vite, oui. Mais fuzzer un programme de 8 lignes, ça n'intéresse personne (même moi, sans ordinateur rien qu'en lisant le code source je peux trouver la condition d'erreur \o/ )
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 8.
T'es gentil :)
Je te rappelle donc que j'ai passé 13 ans à MS. A peu près 8 de ces années ont été passées à construire des fuzzing frameworks et fuzzers. SAGE j'ai revu son design, je l'ai utilisée de manière répetée moi-même, j'en ai parlé avec les auteurs directement, j'en ai parlé avec des dizaines de testeurs et ingénieurs sécurité qui l'utilisent, j'ai vu les bugs qu'il a trouvé, je sais exactement comment il fonctionne et ce qu'il faut pour qu'il fonctionne.
Tu en sais quoi ? Tu n'a aucune idée de la manière de l'utiliser. Et devines quoi, tu as totalement tort.
C'est parce que tu ne lis pas au bon endroit. Lien donné par Benoit Sibaud plus haut : http://research.microsoft.com/en-us/um/people/pg/public_psfiles/SAGE-in-1slide-for-PLDI2013.pdf
1/3 des bugs trouvés dans les composants desktop & multimedia de Windows 7 l'ont été par SAGE. Ca inclue tout ce qui est PNG/JPG/MPG/… et bien plus, et c'était donc avant 2009, SAGE a été optimisé et amélioré depuis pour optimiser ses prioritizations de branches et sa manière de surveiller les processus.
Tu peux lancer SAGE sur Word ou Excel donc, c'est légérement plus qu'un soft de 8 lignes.
Tu as visiblement focalisé sur le fait que SAGE vient de MS Research, et donc est probablement juste un projet de recherche inutilisable dans le monde réel. Tu as faux sur toute la ligne, c'est un projet qui a été construit dans l'idée de l'utiliser en production, par des testeurs normaux, pour trouver des bugs, et il en trouve à la pelle.
J'ai dit plus haut que c'était le système le plus efficace que j'ai jamais vu, je dis ça en connaissance de cause. Je connais Sulley, Peach, AFL, SAGE, les fuzzers que j'ai construit moi-même, Codenomicon, … SAGE les éclate tous en ce qui concerne le fuzzing de fichiers (pour le traffic réseau c'est une autre pair de manche vu le coté transactionnel des protocoles réseaux)
[^] # Re: Rien de nouveau
Posté par Kerro . Évalué à -1.
Si SAGE donnait de bons résultats, ce serait un produit connu, vendu et/ou livré avec Visual Studio.
En fait même s'il donnait des résultats moyens, vu que Microsoft n'a aucune hésitation à sortir des trucs honteux lorque l'occasion se présente (je pense en particulier à Microsoft Dynamics NAV, anciennement Navision, car je l'ai connu, mais il y a bien d'autres exemples).
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 3.
LOL, justement non. MS ne fera jamais cela, pour la même raison qu'aucun des outils que j'ai développé là-bas n'a été publié.
Si MS publiait un outil offensif comme SAGE ou autre fuzzer non ridicule (ils ont publié un minifuzz qui était un gros gag et qui ne trouvera jamais rien de sérieux, il a été publié principalement pour que des débutants puissent gentiment se mettre à faire des tests de sécurité) les gens utiliseraient un outil MS pour attaquer des softs d'éditeurs et clients de MS, voire des softs MS. MS ne veut certainement pas entuber tout le monde en faisant ca, et n'a certainement pas envie que des gens trouvent des failles dans ses softs, avec ses propres outils d'attaque.
Et pour le premier guignol qui voudrait sortir "si ils avaient fait tourner ces softs eux-même personne ne trouverait de failles dans les softs MS", j'invite ce guignol potentiel à s'informer et comprendre comment des softs qui doivent explorer un espace de recherche infini fonctionnent.
Ce que j'aime chez toi c'est cette force à parler de trucs dont tu ne connais rien et dire qu'ils sont à chier.
[^] # Re: Rien de nouveau
Posté par Zenitram (site web personnel) . Évalué à 10.
Ca fait un peu bisounours la "je ne diffuse pas pour te protéger".
Si MS le fait, je ne doute pas que d'autres trouveront un jour la même méthode.
On peut aussi dire qu'il vaut mieux se prendre un gros "boum" dans la gueule le plus tôt possible (par exemple avant la release?)
Alors bon, autant être honnête et dire qu'on veut garder un avantage concurrentiel sur les autres…
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 2.
Ce n'est pas spécialement "pour te protèger" (quoique ca joue un peu), mais plutôt pour "que tu ne me fasses pas la gueule quand ils t'attaquent, et que je n'aie pas l'air con si ils trouvent des failles dans mes propres softs"
Rien à voir avec l'avantage concurrentiel. J'ai vécu la chose personnellement, je suis sur à 100% de la raison. Je ne l'aime pas beaucoup, mais je la comprend d'un point de vue business.
[^] # Re: Rien de nouveau
Posté par Yann Droneaud (site web personnel) . Évalué à 1.
Ne pas mettre cet outil à disposition dans l'éco-système Windows me semble être une forme de "non-assistance à personne en danger" ?
Il y a des failles, partout, dans tout, et là, nous aurions un éditeur qui ne donnerait pas les moyens à ses partenaires de fiabiliser leurs propres produits/solutions, … pour … les … protéger … ?!?
La sécurité, c'est déjà une course à armes légèrement inégales entre les vilains qui disposent de moyens toujours supérieurs à ceux des gentils, mais si l'un des plus gros éditeurs de logiciels oblige ses partenaires à concourir avec des béquilles carrées (TM), on peut être sûr des résultats.
"Tu ne le sais pas encore mais tu es déjà mort", merci Microsoft !
N'oubliez pas Hackers don't give a shit to …1.
Damned, je ne retrouve pas l'image d'origine, beaucoup plus lisible. ↩
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 1.
Obliger à concourir avec des béquilles? Tu te fiches de qui là? MS n'obliges personne à quoi qu ce soit. Il ne donnent pas leurs outils internes c'est leur choix, rien n'empêche les autres de développer eux même, se mettre ensemble pour développer… des outils.
Faudrait quand même arrêter avec cette obsession a vouloir critiquer MS à tout prix, ca en devient pathétique.
[^] # Re: Rien de nouveau
Posté par barmic . Évalué à 7.
Ça ressemble beaucoup au gars qui devant sa copine explique que « non il ne montre pas comment il est bon au pour ne pas trop en mettre pleins la vue à tout le monde parce que sinon il paraîtra trop imbu de sa personne etc ».
Par contre du coup, il y a une offre pour accéder à se logiciel ? Le genre d'offre que propose CAST pour l'analyse statique de code par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 3.
Non il est en interne uniquement.
Pour ce qui est du coté "vaporware", ben tu peux croire ce que tu veux… ou voir des choses genre http://talosintel.com/files/publications_and_presentations/presentations/Fuzzing_and_Patch_Analysis-SAGEly_Advice.pdf
qui, oh surprise, est une tentative de réimplementer SAGE en open source… par qui ? Par un ancien ingénieur sécurité de MS (ancien collègue à moi plus précisement) qui est maintenant chez CISCO.
On se demande pourquoi, après avoir quitté MS, il essaierait de réimplementer un vaporware…
Ou https://www.syscan360.org/slides/2012_EN_SecurityEngineeringAndProductImprovementsInTheNewOffice_TomGallagher.pdf avec le manager securité d'Office décrivant l'utilisation de SAGE pour Office.
Conspiration globale à travers la boite, et même les ex-employés pour vanter un outil interne qui n'existerait pas ?
On va dire que c'est plutôt amusant comme idée, mais pas très réaliste.
[^] # Re: Rien de nouveau
Posté par barmic . Évalué à 3.
Non pas du tout c'est ton argument qui fait bidoné. Sage je suis bien incapable de comprendre les papiers qui sont présentés.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de nouveau
Posté par Kerro . Évalué à 1.
Microsoft ne publie pas un logiciel permettant d'améliorer le code… afin de protéger le monde.
Mais bien sûr.
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 0.
Ton opinion biaisée à l'emporte pièce sur MS, on va dire qu'elle vaut ce qu'elle vaut tu sais…
[^] # Re: Rien de nouveau
Posté par Kerro . Évalué à -6.
Ton argument est foireux puisque TON opinion est tellement biaisée que les administrateurs de ce site sont obligés de « blanchir » ton compte tellement tu as un karma ultra négatif.
[^] # Re: Rien de nouveau
Posté par Kerro . Évalué à -6.
Ou tu as fait pendant plusieurs mois uniquement des commentaires très lisses afin de remonter, je ne sais plus.
Une sorte de cure.
[^] # Re: Rien de nouveau
Posté par octane . Évalué à 8.
oui je sais, merci :)
oui, bah tu vas dans mon sens. On a une communication opaque qui dit que Sage c'est génial et mieux que les autres. Vas sur fulldisclosure, sur le MITRE, et cherche les bugs trouvés par Sage.
oui, et afl qui a mouliné quelques jpg a trouvé de nouveaux bugs dans des produits microsoft. OMG! le fuzzer le plus perfectionné au monde qui ne travaille pas au hasard et qui prend tous les branchements de code aurait laissé passé un bug? Mais comment est-ce possible?
Imagine, tu as une fonction a(), une fonction b().
Sage va être capable de te dire que tu es allé dans a(), que tu es allé dans b(). Et ne trouve aucun crash. Et il s'arrête là. 100% de code coverage. 100% de branchements d'exécutions. Le solveur a bien travaillé et a trouvé comment aller dans a() et dans b(). Mais le résultat, c'est 0 crash.
afl, tout simple et bête qu'il est, va être capable de dire, tiens le chemin d'exécution:
a() -> b() est différent de b() -> a(). Et différent de a() -> a() -> a() -> b() -> a() -> crash!
Mais ne te méprends pas. Je trouve que Sage, c'est très bien. C'est juste une réponse incroyablement complexe à un problème simple (explorer efficacement le code compilé). Et c'est génial (si si). Mais incroyablement compliqué. Sage, ça reste ardu à mettre en oeuvre. Les équivalents, idem. C'est lourd, c'est long, ça demande un temps délirant à démarrer et il faut 25 ingénieurs qui le surveillent en permanence.
A côté de ça, face au même problème: explorer efficacement le code compilé, tu as des fuzzers comme afl qui éclatent littéralement tous les autres fuzzers en terme de facilité d'utilisation, et qui trouvent des bugs, même lorsque Sage est passé par là!!
Un fuzzer "dumb" à la radmasa, oui, ça a beaucoup de limites. Pour faire péter ces limites, tu peux faire Sage. Combien d'années de recherches à MS? Combien d'années.hommes? Et tu as afl. Quelques semaines de taf d'une personne. Nombre de bugs trouvés: énormes. Il faudrait que MS research porte afl sur leurs produits et teste un coup. Je serais très curieux du résultat.
[^] # Re: Rien de nouveau
Posté par woffer 🐧 . Évalué à 2.
Effectivement, la simplicité d'utilisation de ces outil et leur disponibilité grâce à leur licence les rendent complètement génial.
On peut facilement imaginer mettre ce genre d'outil dans nos processus d'intégration continue (via un Jenkins ou autres) et les faire tourner toutes les nuits durant nos processus de développement afin de trouver au plus tôt une partie importante des failles/crashs.
Comme le mécanisme de corpus est simple à mettre en place mais surtout très efficace. Le mécanisme de fuzzing s'adaptera dans la nuit aux évolutions du logiciel faites dans la journée.
Bref, j'adore :)
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 7.
Comment ? Ben en comprenant que les branches ca ne fait pas tout, et qu'explorer toutes les branches prend un temps infini. C'est pas pour rien qu'au premier post j'ai parlé d'asymptotique.
Parce que tu crois que SAGE ne connais que a()->b() ? Mais tu n'as vraiment rien compris à SAGE mon cher ! Il suit l'execution depuis le debut du processus, il ne se limite pas un subset.
Mais arrètes de raconter n'importe quoi… SAGE c'est un répertoire avec executables et libraries, c'est un executable a lancer avec diverses options, tu mets 1h grand maximum à comprendre comment le lancer et quelles sont les options principales, et tu peux le lancer à l'aveugle avec des options de base en 5 minutes.
C'est quand même dingue… tu ne l'as jamais utilisé, et tu essayes d'expliquer à un gars qui l'a utilisé de manière répetéee comment il marche…
C'est ta naiveté qui te fait croire que MS ne connait pas AFL et ne l'a jamais utilisé et testé ?
[^] # Re: Rien de nouveau
Posté par octane . Évalué à 3.
Je snippe tout, ce n'est pas intéressant. Ca continue dans la lancée: "tu n'y connais rien, say génial et tu n'y connais rien".
Non, c'est le manque de communication à ce sujet, mais peut-être qu'un ingénieur qui a passé 13 ans chez Microsoft pourra pallier à cette absence.
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 4.
C'est pourtant simple. MS a des dizaines et dizaines d'ingénieurs sécurité et a (avait ?) des milliers de testeurs, dont l'objectif est de trouver des bugs.
Vu l'objectif, ils essayent évidemment tout ce qui se trouve à l'exterieur, car c'est évidemment plus facile d'utiliser un truc existant qu'un truc qui n'existe pas et qu'il faut écrire. Il y a d'autres contraintes qui entrent en jeu aussi, genre le support disponible, possibilités d'intégration, voire même la licence, mais évidemment que les groupes sécurité MS regardent tout ce qui est publique est recommandé publiquement, ils ne sont pas stupide.
[^] # Re: Rien de nouveau
Posté par groumly . Évalué à 8.
Ben d'un autre cote, sage, t'y connais effectivement rien, donc il a pas forcemment tort, hein.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Rien de nouveau
Posté par octane . Évalué à 10.
Tu es gentil, mais le fuzzing, je bosse dedans, justement :)
Donc oui, Sage, je connais, egas aussi, j'ai pas mal discuté avec son auteur. Et je maintiens ce que je dis: Sage, c'est une espèce de tank couplé à une usine à gaz pour décapsuler une cannette de bière. Ca marche, c'est long, ça a demandé des années de mise en oeuvre et ça fait à peu près le job. Mais écoute pasbillpasgates: moi qui bosse depuis 13 ans là dedans, il me faut 1h pour lancer une campagne de fuzz. Whah! Imagine un dev qui te dise qu'il code depuis 13 ans dans un langage et qui a besoin d'1h pour écrire Hello World. Tu dirais que ce langage n'a pas l'air simple.
Je crois que c'est surtout une affaire d'ego. Tu es face à des gens qui ont eu comme leitmotiv pendant des années la seule phrase: "le fuzzing aléatoire c'est de la merde".
Ils ont passé des années à développer un bouzin, à inventer des technos, à faire du beau logiciel, ça a donné beaucoup de papiers de recherches, et ils sont toujours fier d'annoncer que Sage a trouvé 1/3 des bugs dans je ne sais plus quel composant d'Office. Le gars qui a fait Egas, c'est amusant, c'est toujours la première chose qu'il sort: "si si, say génial, ça a trouvé le 1/3 des bugs d'office" sans plus de détails. Va voir une de ses présentations à une conf, la moitié de la présentation sert surtout à dire que c'est mieux que les autres et que les fuzzers n'arriveront jamais à trouver tous les bugs (sage non plus, mais ça les choque moins). L'autre moitié de la prez sert à expliquer comment ça marche, et allez les lire, ça n'a rien de simple.
Je comprends que c'est un peu difficile de se remettre en question: les devs de sage ont fait un gros bouzin, de la taille d'une montagne, et un gus sorti de nulle part publie un soft de quelques lignes qui explose en facilité leur tank.
Première réaction: quoi, un fuzzer aléatoire? Mais ça fait dix ans qu'on répète que c'est de la merde, alors c'est de la merde.
Deuxième réaction: de toute façon, notre fuzzer est beaucoup mieux.
Troisième réaction: moi j'y ai bossé 10 ans dessus, alors c'est mieux et je sais de quoi je parle.
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 3.
C'est là ou tu as tout faux. De nouveau tu fais des supputations sur ce que tu ne connais pas.
J'ai passé la majorité de ma carrière à faire des fuzzers oui. Je n'étais pas dans l'équipe qui a fait SAGE par contre. C'est une autre organisation. Mes fuzzers étaient du type pseudo-aléatoire et pas des solveurs.
Je n'ai aucun intérêt personnel à aller dire que SAGE est le top du top. Ce n'étais ni moi ni mon groupe et ce n'est plus ma boite depuis 2 ans. C'était plus proche d'un concurrent a mon travail qu'autre chose mais je regarde la chose honnêtement, c'est simplement un constat de ce que j'ai vu.
Mais visiblement tu as du mal à accepter une opinion qui va contre la tienne.
[^] # Re: Rien de nouveau
Posté par barmic . Évalué à 8.
Non, c'est l'exploration des chemins qui prend un temps infini, l'exploration des branches est réalisable.
Pour quelqu'un qui a passé 8 ans à travailler avec c'est un normal quelque soit le logiciel.
En même temps qui ce serait ? Ça ne sert à rien de s'intéresser à la simplicité ou non du bouzin s'il y a tout juste quelques dizaines de personnes qui y ont accès1. C'est apparemment suffisamment simple pour eux et tant mieux.
Du coup c'est très simple d'utilisation et c'est utilisé, mais pas trop (MS a peur que d'autres l'utilisent encore mieux sur nos propres logiciels). MS a peur des failles que ça montrerait chez les autres (qu'est-ce qu'il est serviable ce MS), mais il ne va pas non plus leur dire ce quels sont leur failles (hum pas si serviable en fait) ni même proposé de service pour permettre à d'autres de le lancer sur leurs propres logiciels (hum vraiment pas cool).
C'est quoi le plan vu que tu a était dans le secret des dieux ? Se toucher la nouille en expliquant qu'on a la plus grosse mais en la cachant du mieux que l'on peut ?
Je dis ça mais je présume qu'il y a aussi quelques personnes à Fort Meade qui s'amusent avec et que ça arrange bien de ne pas voir SAGE distribué publiquement ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à -1.
Oui, mauvaise utilisation de termes, c'est évidemment les chemins que SAGE suit.
Ah si seulement c'était vrai, ca me ferait plaisir…
T'as raté la partie ou MS Research a publié plusieurs papiers décrivant ce qu'ils font ?
Il n'y a que le code source qui compte maintenant ?
[^] # Re: Rien de nouveau
Posté par barmic . Évalué à 6.
Ou est-ce que j'ai parlé de code source ? J'ai même parlé de proposé du service uniquement (sacs laisser les clients accéder au logiciel).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à -2.
Belle idée, on y avait réflechi (pour des outils autres que SAGE), et au final ce n'était pas faisable car :
a) Il faudrait un moyen de s'assurer que la personne est vraiment l'auteur du soft --> etape manuelle et couteuse
b) Il n'est vraiment pas simple de supporter un utilisateur qui n'a pas acces au soft, donc pas la possibilité de voir tout ce qui se passe de près, à moins d'investir sérieusement dans l'UI, logs, etc… il fera régulirement appel au support, et c'est chiant
c) Il faut gérer le cas ou le gars te fait un upload de son soft qui n'est qu'wrapper qu'il utilise pour tester le soft de qq'un d'autre, pas simple
d) C'est bien trop d'efforts pour un truc qui au final n'est pas le coeur de métier de l'organisation ou j'étais. Cette org ne s'occupe pas de sécuriser la planète, mais les softs et services MS.
[^] # Re: Rien de nouveau
Posté par barmic . Évalué à 2.
Je parle de faire de vendre un service d'expertise. C'est extrêmement chère pour le client et c'est du service à très haute valeur ajoutée. Ça demande en effet une étape de vérification (mais déjà le coup de ce genre de service réduit tellement le nombre de clients) et ça consiste à recevoir le programme avec une preuve que le code source appartiens bien au client et à fournir soit le rapport complet sorti par SAGE soit à minima les entrées qui permettent de rejouer l'échec (tu peut même dans le contrat contraindre le client à faire de la publicité sur le fait que ton service à découverts des failles).
Il y a des dizaines d'entreprises qui font ça (et qui sont tout à fait rentable), ça n'est pas infaisable loin de là. Après je peux comprendre que MS ne le fasse pas, mais faut pas être surpris de se faire rallier par le tout venant n'importe quel fuzzer (y compris minifuzz dont tu parlais) à probablement plus contribuer à la sécurité informatique que SAGE utiliser sur quelques logiciels en tout est pour tout dans sa vie. Investir autant pour aussi peu de résultat1 est assez risible.
pas dans le sens que sage soit bon ou pas, mais que le résultat final c'est « un moins de failles dans quelques logiciels » ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 1.
Dépend comment tu vois ca. SAGE a aidé à sécuriser des softs comme Word, Excel, Windows,… et a trouvé un sacrément large nombre de bugs dedans durant leur développement. Quand tu penses au nombre d'utilisateurs de ces softs, je te dirais que très peu de fuzzers ont eu un tel impact.
Maintenant, est-ce qu'il aurait pu avoir un impact bcp plus large en étant public, c'est évident que oui.
[^] # Re: Rien de nouveau
Posté par Zenitram (site web personnel) . Évalué à 2.
Un peu contradictoire avec un précédent commentaire de toi mais finalement on est d'accord :).
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . Évalué à 1.
Aucune contradiction.
Ne pas vouloir être considéré comme responsable de la découverte de failles par des blackhats != vouloir sécuriser la planète
# preuve formelle ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Cela ressemble à des outils de preuve formelles. Dans la suite logiciel Esterel, il y avait un moyen de générer une suite d'entrée pour faire la couverture totale du code avec un outil comme prover. Ensuite, il fallait avoir écrit les conditions de validité du code (genre d'assertion). C'est l'inverse de la preuve de théorème qui ne fait que chercher un contre-exemple.
Ce genre d'approche (la génération d'entrée) est très critiqué car on semble tester un code avec lui-même. Beaucoup de gens ne font pas la différence entre la génération de pattern d'entrée (l'ATPG est pourtant un téchnique obligatoire en fabrication de puce) et la présence d'assertion ou d'oracle définit forcément à la main, car lié à la spécification de plus haut niveau.
Si vous employez un langage qui ne permet ni dépassement de capacité, ni d'allocation mémoire, ni … boucle, c'est difficile de trouver des oracles évidents, puisque qu'il n'est pas possible d'écrire ce genre de bug. La difficulté réside ensuite dans l'écriture des assertions.
"La première sécurité est la liberté"
[^] # Re: preuve formelle ?
Posté par Thomas Douillard . Évalué à 2.
Le soucis évident d'un approche formelle est justement que dans bien des cas on a une énorme base de code existante … qui n'a pas suivi une approche formelle :)
Dans ces cas là sauf à vouloir tout spécifier après coup en version plus haut niveau et tester la conformité du code à la spec, on doit recourir à des approches un peu plus light. Évidemment dans un langage qui compile pas si il y a un débordement de tampon, ce genre d'approche est moins utile.
[^] # Re: preuve formelle ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est toujours le problème d'avoir les oracles.
"La première sécurité est la liberté"
# Un exemple d'application sur LibreOffice
Posté par Jean-Baptiste Faure . Évalué à 5.
AFL est testé sur LibreOffice : http://caolanm.blogspot.com/2015/10/finding-ui-crashes-by-fuzzing-input.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.