"rung"

• [^]Re: "rung"

  Posté par Charles-Victor DUCOLLET () le 06/02/2008 à 21:36. (lien). Évalué à 3.

  +1 on comprend mieux comme ça !

• [^]Re: "rung"

  Posté par fleny68 () le 06/02/2008 à 21:52. (lien). É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 ?

  --
  Non, rien

  • [^]Re: "rung"

    Posté par Benjamin G. ( Prae ) (page perso, ) le 07/02/2008 à 00:48. (lien). É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/02/2008 à 15:11. (lien). Évalué à 2.

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

      --
      Linux ! Mettez un manchot dans votre moteur !

Profil bas

Et le fuzzing alors ?

• [^]Re: Et le fuzzing alors ?

  Posté par khivapia () le 07/02/2008 à 11:25. (lien). É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 (Jabber id, page perso, ) le 07/02/2008 à 23:09. (lien). É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.

  --
  Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
  pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

  • [^]Re: Et le fuzzing alors ?

    Posté par Victor STINNER (page perso, ) le 08/02/2008 à 03:11. (lien). É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/02/2008 à 21:35. (lien). É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"