Journal Devons-nous nous méfier des logiciels Open Source ?

Posté par  (site web personnel) .
Étiquettes :
0
16
sept.
2005
Une interrogation m'a effleurée l'esprit aujourd'hui. Devons-nous nous méfier des logiciels Open Source ?

Je m'explique: En tant que linuxiens avertis nous ne faisons peu ou pas confiance aux binaires qui peuvent, à notre insu, se révéler pleins de surprises. Le genre de surprises que l'on aime pas, des « espions logiciels » et autres saletés. Mais heureusement, nous utilisons des logiciels dont les sources sont librement accessibles et qui nous mettent en confiance sur la qualité et le respect de nos libertés.
Nous leurs accordons une confiance aveugle, mais combien d'entre nous regardent vraiment les sources et les explorent ? Personne à part les développeurs. Eh oui! Quel intérêt d'explorer les entrailles de KDE ? Tant que nous n'avons pas un besoin précis de les modifier et quand bien même nous devons les modifier pour nos besoins personnels qui est capable de certifier qu'elles ne contiennent pas une « porte dérobée » ou un « espions logiciels » ?

Evidemment, me direz-vous le risque serait trop grand pour une communauté de développeurs d'être complices d'une telle tricherie. Mais dans les centaines voir milliers d'applications qui tournent sur nos machines, maintenues par un ou plusieurs programmeurs n'y a-t-il pas un risque ?

Le risque est encore plus grand dans les distributions fournissant des paquets, binaires où non, puisque cette facilité nous permet d'installer sans compter des tonnes d'applications.
Imaginez maintenant une distribution à paquets binaires, telle une debian (très utilisé dans les serveurs à travers le monde), comment peut-on vérifier qu'un « .deb » n'a pas été patché avec un méchant « malware » ? Soit volontairement par son mainteneur / développeur où par un piratage d'un des miroirs ? (Pour les miroirs il y a souvent un checksum il est vrai, mais si le miroir « source » était touché ?) Des milliers de serveurs potentiellement à la merci de pirates.

La psychose s'installe... ? ;o)

Je suis sûrement en plein délire, mais le risque est bien là, et s'accroît avec l'essor et la démocratisation de Linux.

Qu'en pensez-vous ?

  • # Debian, fedora, ... & gpg

    Posté par  . Évalué à 6.

    Les packages debian et fedora (surement d'autres, mais je ne connais pas vraimment les autres distributions) integrent un systeme de signature des paquets via gpg.

    Ainsi, meme si le serveur source des packages est touche, a moins que le devellopeur ne se soit fait pirate sa cle gpg, il n'est pas possible (ou pas) de 'patcher' un package.

    Ta reflexion est cependant tres pertinente au niveau du travail fait sur les sources elles-memes. Au niveau des packages proposes par les distributions, il y a moins de chances pour que les sources contiennent une backdoor ou autre. De plus, il me semble qu'il y a partout dans le monde des personnes chargees de l'audit du code de ces fameux logiciels libres.

    • [^] # Re: Debian, fedora, ... & gpg

      Posté par  (site web personnel) . Évalué à 5.

      De plus, il me semble qu'il y a partout dans le monde des personnes chargees de l'audit du code de ces fameux logiciels libres.

      Ah bon, qui ça ?

      • [^] # Re: Debian, fedora, ... & gpg

        Posté par  (site web personnel) . Évalué à 8.

        bah eux

      • [^] # Re: Debian, fedora, ... & gpg

        Posté par  (site web personnel) . Évalué à 4.

        Il y a quelques temps il y avait un projet (Sardonix) fondé par le DARPA pour auditer un max de logiciels libres mais apparement ça a pas duré. Ca serait bien que ce genre de projet revienne à la mode (on peut rêver).

        http://web.archive.org/web/20041123090110/http://www.sardonix.org/(...)

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

      • [^] # Re: Debian, fedora, ... & gpg

        Posté par  (site web personnel) . Évalué à 1.

        Les listes de diffusion de sécurité sont aussi nombreuses qu'actives.

        Parmi les plus connues on trouve Bugtraq et Vuln-dev (infos sur http://www.securityfocus.com/(...) ).

        Les personnes qui postent dans ces mailing-lists sont, par exemple, des personnes rémunérées par leur entreprise (image de marque, toussa), des individus qui vendent leurs services en tant qu'experts en sécurité et qui ont là une occasion de prouver leurs compétences, des h4><0rz boutonneux, des quidams qui sont tombés par hasard sur un bug plus ou moins grave, etc. etc..

        Les discussions sont intéressantes et instructives, mais le rapport signal/bruit est parfois faible. Pour ça, le "digest" quotidien est idéal car il permet de parcourir rapidement les sujets de la journée et les logiciels concernés. À noter qu'il existe souvent des fils RSS/Atom.

        • [^] # Re: Debian, fedora, ... & gpg

          Posté par  (site web personnel) . Évalué à 2.

          J'avoue que je ne lis pas régulièrement Bugtraq mais il me semble qu'on y trouve plus des failles ponctuelles que des résultats d'audits de code complets.

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

          • [^] # Re: Debian, fedora, ... & gpg

            Posté par  (site web personnel) . Évalué à 2.

            On trouve des failles à des endroits ponctuels du code (ce qui s'approche de la tautologie), qui font parfois suite à des audits complets de code, parfois à un (mal)heureux hasard, parfois un mélange des deux, parfois un audit d'une partie particulière du code, ...

            Autrement dit, tu ne vas pas avoir de remarques complètes sur l'intégralité d'un code donné, etc., mais des remarques "choisies" sur des parties dangereuses de plusieurs programmes.

            Après, si tu recherches une étude approfondie d'un logiciel en particulier, peut-être que certaines personnes font des audits complets et publient les résultats de leur analyse sur leur site, en ne postant que les problèmes de sécurité sur les listes de diffusion idoines.

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Devons-nous nous méfier des logiciels Open Source ?

      Posté par  . Évalué à 4.

      > Maintenant, il me semble avoir lu ici que la dernière Debian vérifie par défaut les signatures GPG des paquetages (par la
      > signature d'un fichier de sommes de contrôle). Un Debianais pourra confirmer ou infirmer.

      En unstable oui, depuis quelques mois, et donc surement aussi en testing, mais pas encore en stable. C'est une des fonctionalités qui a attendu la stabilisation de Sarge pour pouvoir sortir.

      En pratique, lorsque tu tentes d'installer un package non-signé (maintenant, ce ne peuvent plus être que des packages non-officiels), on te demande expressément de confirmer (ou infirmer) leur installation.
      Je ne suis pas encore tombé sur un cas où la signature d'un package demandé n'était pas valide, mais je pense que dans ce cas là, apt refuse inconditionnellement de l'installer (comme c'est par exemple déjà le cas lors d'un mauvais checksum).

      • [^] # Re: Devons-nous nous méfier des logiciels Open Source ?

        Posté par  (site web personnel) . Évalué à 4.

        Ce n'est malheuresement pas encore le cas de toutes les distributions. Elles tardent à mettre en oeuvre ces pratiques de sécurités, beaucoup fonctionnent encore avec une simple vérification md5 (voir même aucune ?).

        • [^] # Re: Devons-nous nous méfier des logiciels Open Source ?

          Posté par  (site web personnel) . Évalué à 2.

          Sous Gentoo la signature GPG n'est encore qu'optionnelle mais d'après ce qu'ils annoncent ça devrait assez vite devenir systématique :)

          (Donc pour l'instant que MD5 oui. :-\)

          • [^] # Re: Devons-nous nous méfier des logiciels Open Source ?

            Posté par  (site web personnel) . Évalué à 0.

            Sous Gentoo la signature GPG n'est encore qu'optionnelle

            Gentoo serait à la ramasse par rapport à Debian. Nooon, pas possible !

            • [^] # Re: Devons-nous nous méfier des logiciels Open Source ?

              Posté par  . Évalué à 1.

              > Gentoo serait à la ramasse par rapport à Debian. Nooon, pas possible !

              Non non, ce n'est pas ça... depuis des lustres, gentoo fournit un hash MD5 de ses paquets de sources :
              - le hash est sous /usr/portage/cat/nom_du_paquet/Manifest et est téléchargé lors du "emerge sync" sur les serveurs rsync.
              - le paquet est téléchargé lors du "emerge blah" donc sur d'autres serveurs : ceci est clairement un point positif niveau sécu sur ce que faisait debian.

              L'histoire de la signature GPG concerne la certification de l'intégrité des ebuilds ("emerge sync"...), et également des fichiers téléchargés lors du emerge sync (parfois quelques mini-patches en particulier).

              En fait les ebuilds pouvaient être modifiés par l'administrateur d'un miroir gentoo sans que personne n'y prenne garde... (!) Et, même si ce ne sont pas des programmes au sens de "paquet logiciel", les ebuilds sont des scripts qui s'exécutent, doooonc...

              M'enfin, à force de mettre des signatures partout, on ne pourra bientôt plus modifier à la main les ebuilds et les patches sur sa propre machine (par exemple pour ajouter un patche perso ou modifier les options du ./configure), ça risque de devenir pénible :( Enfin, on verra...

    • [^] # Re: Devons-nous nous méfier des logiciels Open Source ?

      Posté par  (site web personnel) . Évalué à 4.

      C'est pas parce qu'un paquet est signé par le ftpmaster qu'il ne contient pas de backdoor. Parmi les centaines (milliers?) de packageurs Debian, il peut toujours bien y en avoir un qui peut avoir introduit une backdoor en toute discrétion. Et même si ça n'est pas le cas, ça peut avoir été fait par l'auteur en amont tout aussi discrètement. Par contre pour que ça reste indétecté faut vraiment avoir bien pensé le truc à la base (surtout pour un paquet très utilisé).

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

      • [^] # Re: Devons-nous nous méfier des logiciels Open Source ?

        Posté par  . Évalué à 6.

        Il faut aussi compter sur le fait qu'une grande partie des utilisateurs Linux sont réellement des experts en sécurité/administration (comme en close source) ou simplement trés curieux.
        Et si l'un deux découvre un comportement suspect/ inhabituel (process, socket, utilisateur ... ) ; il y a tout les outils nécessaires pour remonter à la source du phénomène - je pense aux méthodes de sniffing, chkrootkit - qui peuvent sonner l'alerte et l'accés aux sources qui pourra la confirmer ou l'infirmer (contrairement au close source).

        Donc, c'est réellement le grand panel d'utilisateurs et l'accés aux sources qui garantissent l'absence de malware.
        Attention cepandant, il n'y a pas de garantie qu'un binaire ou source tendancieux ne sera un jour livré, mais qu'une fois livré, il sera assez rapidemment détecté et contré.

        • [^] # Re: Devons-nous nous méfier des logiciels Open Source ?

          Posté par  (site web personnel) . Évalué à 2.

          je pense aux méthodes de sniffing

          Très juste, je n'avais pas pensé à cette éventualité. Pourtant le sniffing et même l'analyse réseau à coup d'ethereal est très courant chez nos administrateurs réseaux. On peut donc en penser que si des paquets suspects venaient à se balader ils seraient rapidement identifiés.

  • # De toute façon...

    Posté par  (site web personnel) . Évalué à 6.

    Euh, je dois être un peu tarte mais il faudra m'expliquer en quoi cela pourrait être un argument en défaveur de l'expansion de linux, puisqu'avec un logiciel opensource.... bah on a les sources. Qui peut le plus peut le moins, je préfère analyser du C que de l'assembleur.
    Par contre, la problématique sur la fiabilité de la provenance des logiciels est intéressante, tout simplement parce que dans le monde du libre, on s'adresse moins souvent à des entreprises qu'à des particulier s ou des fondations et on a tendance à penser (à tort ou à raison) que plus un interlocuteur est professionnel et propre sur lui, et plus on peut lui faire confiance. L'expérience montre, en tout cas, ME montre que ça serait plutôt penser à tort.

    • [^] # Re: De toute façon...

      Posté par  (site web personnel) . Évalué à 6.

      Le problème c'est que le binaire que tu télécharges ne correspond pas forcément à la source que tu peux inspecter (ou qui a été auditée), même si tu compiles toi même (suffit que ton gcc soit troyanisé aussi). Donc ça peut donner un faux sentiment de sécurité, ce qui est pire que d'avoir moins de sécurité mais d'en être conscient.

      Le tout c'est de savoir que le LL c'est pas miraculeux non plus.

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

  • # ...

    Posté par  . Évalué à 9.

    Le risque est encore plus grand dans les distributions fournissant des paquets, binaires où non, puisque cette facilité nous permet d'installer sans compter des tonnes d'applications.
    N'oublis pas de verifier que ton compilo n'a pas de backdoor. Et puis une fois que tu l'auras auditer, tu te poseras la question comment le compiler...

    • [^] # Re: ...

      Posté par  . Évalué à 1.

      Il me semble qu'a une lointaine epoque, un compilateur embarquait une backdoor qui etait activee lorsqu'il compilait un truc genre login ou telnet.

      Concernant la compilation du compilateur, c'est un gros probleme !
      A la rigueur, il faudrait utiliser plusieurs compilateurs totalement differents et compare les resultats binaires afin de s'assurer de l'abscence de backdoor, mais je ne suis pas sur de la faisabilite de cette technique.

      • [^] # Re: ...

        Posté par  . Évalué à 1.

        Ca me parait clairement infaisable...
        Petit exemple à 2 centimes, en utilisant le meme compilo avec versions différentes:
        bruno@silver:~/tmp$ cat main.c
        #include <stdio.h>
        int main() {
        printf("Hello World!\n");
        }
        bruno@silver:~/tmp$ gcc-3.3 main.c -c -o main.o3
        bruno@silver:~/tmp$ gcc-4.0 main.c -c -o main.o4
        bruno@silver:~/tmp$ ls -l
        total 28
        -rw-r--r-- 1 bruno bruno 63 2005-09-16 21:56 main.c
        -rw-r--r-- 1 bruno bruno 852 2005-09-16 21:57 main.o3
        -rw-r--r-- 1 bruno bruno 868 2005-09-16 21:58 main.o4
        bruno@silver:~/tmp$ diff main.o3 main.o4
        Les fichiers binaires main.o3 et main.o4 sont différents.

        • [^] # Re: ...

          Posté par  . Évalué à 1.

          question conne; comment il faisait pour savoir que c'etait un login ou un telnet ?

          • [^] # Re: ...

            Posté par  . Évalué à 1.

            ben il pouvait par exemple juste regarder le nom du binaire de sortie...

      • [^] # Re: ...

        Posté par  (site web personnel) . Évalué à 3.

        C'est la technique décrite par Thompson dans un papier qui date de 1984 (et l'idée originale remonte à plus loin mais il n'y a pas de référence précise).
        http://www.acm.org/classics/sep95/(...)
        Non seulement le compilo peut inclure une backdoor dans le login(1) qu'il compile mais en plus il inclut de quoi mettre la backdoor quand il recompile le compilateur depuis les sources "propres".

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

  • # le vrai problème.

    Posté par  . Évalué à 6.

    >> n'a pas été patché avec un méchant « malware »

    Bof, il y a suffisament de personnes de milieux différents qui auditent le code source. (De IBM jusqu'au gouvernement chinois, en passant par la NSA)

    Le vrai problème du source libre, c'est l'incompétence des développeurs libres et les inévitables failles de sécu.

    Si des projets comme :

    - Linux, Apache et consort, qui ont une renommée mondiale sont surement très audités et testés.

    - Les projets de moyennes et de petites envergures n'ont peu ou pas de contributeurs, la qualité du projet en terme de sécurité repose donc uniquement sur le mainteneur. Cela peu s'avérer un peu juste en terme d'assurance de qualité.


    Mais le GROS avantage du libre sur le proprio, c'est que tu as les moyens de vérifier si tu as du temps est de l'argent. Rien que ce droit est un avantage :)

  • # t'as tout compris

    Posté par  . Évalué à 3.

    La "securite" repose uniquement dans la confiance que tu as dans la personne/organisation qui te fournit le binaire.

  • # Si on commence à ne plus faire confiance...

    Posté par  . Évalué à 2.

    C'est clair si les utilisateurs de Windows ne font plus confiance à leurs logiciel. Il en utilise un autre contrôler les méchants soft qui accèderaient au réseau sans leur demander l'autorization, mais ont - t - ils réellement confiance en ce logiciel garde du corps de la connexion internet ?

    Parceque par exemple je ne vois pas pourquoi il faudrait faire confiance plus en zone alarm qu'en micro$oft ? Et quand bien même le firewall applicatif serait digne de confiance, est - ce bien sûr à 100% qu'il contrôle tout les accès vers l'extérieur de notre éditeur de redmond préféré :-D. Car c'est quand même lui qui fournit les API donc après dans le kernel, on ne sait pas ce qui se passe.

    Tout ça pour dire que c'est bien si ça rassure les utilisateurs de Windows (c'est pas de leur faute on les a obligé quand ils étaient petits), mais je ne crois pas en la réelle l'efficacité de ce dernier, à mon goùt rien ne vaut le bon vieux firewall de base.

Suivre le flux des commentaires

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