Journal Le gouvernement US paie l'audit de projets libres (la suite)

• # "rung"

  Posté par ArnY (site web personnel) le 06 février 2008 à 22:31. Évalué à 10.

  

  Litteralement "barreau" et traduisible par "echelon" dans le contexte.

  • [^] # Re: "rung"

    Posté par Charles-Victor DUCOLLET le 06 février 2008 à 22:36. Évalué à 3.

    

    +1 on comprend mieux comme ça !

  • [^] # Re: "rung"

    Posté par fleny68 le 06 février 2008 à 22:52. Évalué à 2.

    

    échelon, échelon. ça me dit quelque chose ce terme.
    
    http://fr.wikipedia.org/wiki/Echelon
    
    Le but de l'audit, c'est de vérifier que les projets en question contienne des trous permettant l'espionnage des méchants ?

    • [^] # Re: "rung"

      Posté par Prae le 07 février 2008 à 01:48. Évalué à 9.

      

      oui, tout a fait. Et tu as un gps dans le bloc d`alimentation de ton ordinateur. Fais attention à toi ce soir en te couchant. Une analyse rectale venue d`ailleurs est si vite arrivée...

      • [^] # Re: "rung"

        Posté par Arschney le 07 février 2008 à 16:11. Évalué à 2.

        

        >>Et tu as un gps dans le bloc d`alimentation de ton ordinateur.
        
        ça c'est seulement pour les possesseurs de Mac. :)

• # Profil bas

  Posté par Philippe F (site web personnel) le 07 février 2008 à 11:36. Évalué à 2.

  

  C'est gentil de citer mon journal mais il y a vraiment strictement rien d'interéssant dedans sur coverity scan, juste un troll à deux balles.
  
  Je suis quand même surpris que KDE soit à la traine, il m'avait semblé que les développeurs avaient justement été très réactifs au scan de converity.
  
  Je vais voir ce qu'il en est.

• # Et le fuzzing alors ?

  Posté par Victor STINNER (site web personnel) le 07 février 2008 à 11:49. Évalué à 5.

  

  Si je ne me trompe pas, Coverty fait de l'analyse statique du code source. Ce type d'analyse peut trouver de nombreux bugs qui ont peu de chance de pouvoir réellement se reproduire (car il faut réunir un grand nombre de conditions qui peuvent ne jamais arriver).
  
  Alors qu'avec le fuzzing, on est directement fixé : c'est une analyse dynamique qui teste le programme en cours d'exécution avec de vraies données.
  
  J'avais pensé un jour créer une communauté libre qui viserait à auditer tous les logiciels libres, mais j'ai la flemme de créer ça :-) L'idée serait d'échanger des informations sur les outils d'audit, faciliter la communication avec les éditeurs des logiciels, et se partager les outils pour tester un maximum de logiciels.
  
  Actuellement, je le fais tout seul dans mon coin et quand j'ai du temps. Je teste Mplayer, Gstreamer, Firefox, poppler, libvorbis, etc. J'ai même écrit un outil de fuzzing pour ça :-)
  http://fusil.hachoir.org/trac
  
  Prenez la version stable, la version de développement est en gros chantier pour intégrer un débogueur (ptrace).
  
  PS: Krunch : propose ton texte comme dépêche ! Pourquoi commencer à faire un journal alors que c'est déjà prêt pour une dépêche ??

  • [^] # Re: Et le fuzzing alors ?

    Posté par khivapia le 07 février 2008 à 12:25. Évalué à 7.

    

    Les deux approches sont intéressantes et complémentaires. Une analyse statique permet par exemple de trouver tous les cas (sans exceptions, mais peut-être avec des faux positifs si l'analyse n'est pas assez précise) où on aurait fait une erreur dans la gestion de ses pointeurs, plus généralement de montrer qu'un programme n'a jamais de 'Runtime Exception' (voir par exemple http://www.astree.ens.fr/ : analyse statique des logiciels critiques des Airbus ; bon évidemment ça ne protège pas des bugs liés au matériel). Ça peut aussi permettre de montrer qu'on n'a pas de fuite de mémoire, de dépassement de tampon, etc. etc.
    Tous ces bugs, quoique n'ayant que peu de chances d'arriver, peuvent induire des failles de sécurité importantes, il est nécessaire de les corriger.
    
    Alors forcément puisque l'analyse statique prend en compte toutes les possibilités d'exécution d'un programme, elle est moins précise qu'une analyse dynamique.
    
    L'analyse dynamique elle ne prend en compte que quelques (ça peut être beaucoup mais on ne va jamais tester toutes les valeurs possibles d'un entier aléatoire par exemple... Surtout s'il fait 64 bits ;-) ) exécutions. Elle est plus précise et très ciblée. Par exemple il peut s'agir de vérifier les types d'arguments à l'exécution. Elle fournit moins d'erreurs et permet de cibler beaucoup plus précisément quel type de comportement on veut analyser, en cela elle est tout à fait complémentaire à l'analyse statique.

  • [^] # Re: Et le fuzzing alors ?

    Posté par Krunch (site web personnel) le 08 février 2008 à 00:09. Évalué à 3.

    

    Comme khivapia le dit, l'analyse dynamique ne trouve pas tout, loin de là. Le fuzzing permet généralement de trouver très rapidement des bugs « intéressants » mais il ne permet pas vraiment de s'assurer de la correction du code. Au contraire, l'analyse statique peut trouver tous les problèmes potentiels mais justement, ça fait un peu beaucoup.
    
    Les fuzzers c'est pour les kiddies qui veulent des exploits prêts à l'emploi, l'analyse statique c'est pour les barbus dans les labos qui veulent prouver que le compilateur qu'ils ont écrit pour un langage utilisé par trois personnes dans le monde ne plantera jamais.
    
    PS: Krunch : propose ton texte comme dépêche ! Pourquoi commencer à faire un journal alors que c'est déjà prêt pour une dépêche ??
    J'ai pas vraiment envie de faire passer une pub pour une boîte qui fait du proprio en première page de DLFP (en admettant que ça soit accepté). Si j'avais le temps et la motivation, j'écrirais un article plus complet expliquant comment ça s'est passé pour les projets du rung 2, ce qu'il en est des autres organismes sponsorisés,... mais j'ai même pas suivi tout ça.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Et le fuzzing alors ?

      Posté par Victor STINNER (site web personnel) le 08 février 2008 à 04:11. Évalué à 2.

      

      une pub pour une boîte qui fait du proprio
      
      Le libre n'est pas tout blanc ou tout noir. Autant la société s'offre une publicité gratuite (payé par le gouvernements des USA si j'ai bien compris), autant il y a des résultats : des bugs sont corrigés dans des logiciels libres.

  • [^] # Re: Et le fuzzing alors ?

    Posté par pasBill pasGates le 08 février 2008 à 22:35. Évalué à 4.

    

    Pas d'accord.
    
    L'analyse statique a comme desavantage de donner de potentiels faux positifs(aucun de ces softs est parfait), mais elle permet de detecter des problemes qui sont _reels_ et qui n'auraient _pas_ ete trouves par fuzzing.
    
    Le fuzzing c'est sympa et c'est puissant, mais tu n'arrives jamais a couvrire tous les cas possibles et imaginables. L'analyse statique elle va une etape plus loin en analysant le code et verifiant le type de condition sur le code.
    On utilise les 2 ici et plein de bugs on ete trouve par analyse statique, notamment des buffer overflows ou null references qui ne sont pas forcement clairs dans le code quand ils se trouvent bien profond dans les couches.
    
    Sinon un truc qui est un peu le meilleur des 2 mondes c'est ca : http://research.microsoft.com/research/pubs/view.aspx?type=T(...)
    
    Ce truc est d'une intelligence assez phenomenale, plus besoin de modifier/generer les donnees sans savoir ce que le soft en fait, ici le soft est analyse et les contraintes resolues pour trouver comment les violer, c'est bluffant. Ca a encore besoin d'ameliorations pour etre un tueur, mais c'est deja plus puissant pour tester les parseurs de fichiers que tout ce que j'ai vu jusqu'a present.

• # Petit rappel "culture geeknérale"

  Posté par Vincent (site web personnel) le 08 février 2008 à 18:22. Évalué à 6.

  

  La certification POSIX (officielle) demande une série de tests qui coûte chère. C'est le gouvernement de Bill Clinton qui avait pris sur lui de faire financer la certification POSIX de Linux par le Trésor Américain.

Suivre le flux des commentaires

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