Faille





  • Pour le moment il faut temporiser par rapport à Pfsense. Les trappes ne concerne que Ipsec a priori. Ensuite le noyau FreeBSD pour Pfsense est assez différent d'un FreeBSD basique si je me souviens bien. Juve pourra nous en dire plus sur ce point.
    Enfin il faut attendre les résultats de l'audit du code.

    En conclusion pour un Pfsense qui n'utilise pas Ipsec, je ne suis pas, en l'état des informations disponibles, très inquiet.

    Il semble que je ne soit pas le seul : http://forum.pfsense.org/index.php/topic,31112.0.html



  • Oui il faut prendre tout celà avec des pincettes.

    On est en train de parler de code qui "aurait" été inséré dans le crypto framework d'openBSD au début des années 2000 (bibliothèque de code fournissant les algorithmes de cryptage asymétrique/symétriques, eux meme utilisés par la couche IPSEC d'openBSD). Pfsense utilise une couche IPSEC dérivée (fortement) de cette permière implémentation.
    La "backdoor" "aurait" pour but d'extirper les informations d'échange de clés afin de pouvoir décrypter une transmission IPSEC entre deux équipements.

    La communauté s'est lancée depuis 10 jours à la chasse à la backdoor mais il en résulte qu'il n'y a rien de "malicieux" pour l'instant. Ils ont trouvé des bugs, affectant des fonctions obsolètes.

    Enfin, l'histoire en elle même est assez farfelue, les codeurs n'auraient eut un NDA que de 10 ans…., les personnes citées affirment ne rien avoir inséré, le code a été mainte fois forké sur des produits libres comme payants (n'oubliez pas que darwin, le noyau MacOS, est un fork freeBSD).
    Il est fort probable que les instances de renseignement de différents pays agissent de la sorte, y compri (et de manière contractuelle, avec un cadre définit) avec des produits éditeurs...

    Attendons de voir...


Locked