La mascotte BSD dessinée par Tatsumi Hosokawa
  Chuck's corner (intitulé du site)

Accueil
  Bienvenue !
  Who's that Chuck ?

Articles
  Investigation numérique
  Virtual-to-Remote-Physical
  Prométhée, intranet éduc.
  Frenzy, mini CD live
  Sécu. Open/Closed Source
  Installer FreeBSD 5
  Powered by Unknown !

  En cours d'élaboration :
  Analyseurs d'empreintes

Logiciels
  Portages
  Projet HeV

Liens
  Sites BSD en français
  Liste systèmes BSD
  Projets à l'honneur

Recherche
  avec Logo Google

  sur le site :
  
  sur BSD en général :
  

Les logiciels Open Source sont-ils plus, ou moins sécurisés que les logiciels propriétaires ?

L'article suivant a été initialement publié comme "avis d'expert" dans le cadre de l'étude Rentabilité de l'Open Source, publiée en septembre 2004 par le cabinet Premier Cercle. Il est repris ici dans une version légèrement mise à jour.

Logiciels Open Source : plus sécurisés, ou moins sécurisés que les logiciels propriétaires ?
Les logiciels libres ("free software") ou à code ouvert ("open source") ont bien un avantage structurel décisif en matière de sécurité informatique sur les logiciels propriétaires dont le code est fermé, mais ce n'est pas celui qui est généralement avancé.  Si la disponibilité du code source ne garantit pas la sécurité, la capacité de modifier celui-ci garantit au moins la possibilité d'obtenir un correctif en cas d'exposition à une vulnérabilité.

Certains professionnels de la sécurité informatique ont depuis longtemps remis en question1 l'idée d'une supériorité intrinsèque des logiciels libres ou à code ouvert sur les logiciels propriétaires. Mais le débat n'a gagné le grand public que depuis le début de l'année 2004, surtout depuis la sortie d'une étude2 unanimement contestée par les fournisseurs de systèmes d'exploitation Linux3.

La France n'échappe pas à cette évolution du débat, passant de la vision optimiste des grandes entreprises4 et du gouvernement5 en 2000, à une position plus dubitative des responsables de la sécurité6 en 2004.

S'extraire de la logique partisane

L'intérêt des uns, financier pour les éditeurs, conformiste pour les décideurs informatiques, le dispute à l'idéologie des autres : militantisme des acteurs du libre, croyances des tenants des méthodes de développement à code ouvert7 8 9.

Dans ce contexte, avant de considérer tout avis, il importe de savoir à qui l'on a affaire.

Si, pour ma part, j'ai été responsable d'une offre de services sur les logiciels à code ouvert, je travaille au sein d'un cabinet qui a pour clients quelques uns des plus gros éditeurs de logiciels, et j'y sers notamment des éditeurs de solutions libres comme propriétaires. Par conséquent, je refuse cette polarisation du débat.

Pour moi, la question n'est pas de savoir si l'on est pour ou contre les logiciels à code ouvert ou fermé, mais de comprendre où, quand et comment employer les uns ou les autres. Cela consiste tout simplement à préserver la relation d'ordre entre une expression de besoin et une proposition de solution, tout en se gardant de choisir définitivement un camp.

Ecarter les raisonnements manichéens

Ceci posé, on peut maintenant s'interroger sur la pertinence de la question. Pour cela, il est nécessaire de s'entendre sur les termes et d'en définir la portée.

Dans ce qui suit, on retiendra une définition de la sécurité centrée sur l'utilisateur du logiciel en termes de disponibilité, d'intégrité et de confidentialité des données traitées. Cette définition s'oppose aux préoccupations du fournisseur, qui peuvent être davantage centrées sur la recherche d'avantages concurrentiels10.

Puis, on s'attachera à prendre un maximum de recul afin de dépassionner autant que possible le débat, en évitant notamment les comparaisons au niveau des produits (par exemple, Linux contre Windows) ou des organisations (par exemple, la communauté du Libre contre Microsoft).

La frontière apparaît désormais de toute façon plus brouillée, du fait que les fournisseurs de logiciels éditent parfois des logiciels de l'autre type11, ou incorporent (souvent sans le dire !) des logiciels à code ouvert dans leurs solutions propriétaires...12

Quelques points concrets de comparaison

En définitive, la ligne de démarcation tient surtout, d'une part, à la disponibilité du code source et au droit de le modifier si nécessaire, et d'autre part, à la capacité de le garder secret6 14 15. Dans le cas de Microsoft, par exemple, le programme "shared source"13 ne répond pas à la condition de rendre les modifications possibles.

Le fait qu'un logiciel soit commercialisé ou distribué gracieusement est indépendant et concerne plus le marketing que la sécurité.

Partant de là, passons en revue quelques propositions vraisemblables :

  • La découverte de vulnérabilités
    • C'est plus facile à faire avec le code source que sans ;
    • Ce n'est pas non plus impossible sans le code source, un programme sous forme binaire pouvant toujours être passé au désassembleur ou au débogueur ;
    • Sans le code source, seuls les pirates chercheront probablement des vulnérabilités ;
    • Avec le code source, des développeurs pourraient découvrir et corriger préventivement des vulnérabilités. En pratique cependant, peu de gens prennent la peine de lire les sources - sauf en cas de problème - et leur niveau en sécurité informatique ne les qualifie par toujours pour que l'on puisse faire une comparaison valable avec le processus scientifique de revue par les pairs16 17.
  • La divulgation des vulnérabilités
    • Le nombre de vulnérabilités d'un logiciel n'est pas nécessairement significatif. Celles-ci ne sont souvent comptabilisées que si elles sont découvertes par quelqu'un d'autre que le fournisseur ou des pirates ;
    • L'absence de vulnérabilités divulguées sur un logiciel ne garantit aucunement que celui-ci en soit exempt (personne n'y a peut être regardé !).
  • L'existence de vulnérabilités dans les binaires
    • Il est plus facile de cacher un code malveillant dans un binaire que dans un code source, mais ce n'est pas infaillible non plus18 ;
    • Le fait de disposer du binaire et du code source d'une application ne garantit pas automatiquement que le premier ait été généré à partir du second ;
    • Le fait de générer un binaire à partir d'un code source considéré comme sûr ne garantit pas non plus l'absence de code malveillant ! 19
  • La disponibilité des correctifs
    • On observe que le délai de correction après l'annonce d'une vulnérabilité est généralement meilleur lorsque le code source est disponible20 ;
    • Cependant, le fait qu'un éditeur puisse faire aussi bien, sinon mieux, n'est qu'une question de volonté et de moyens ;
    • C'est un critère peu fiable car il est possible de jouer sur la date de divulgation...
  • La responsabilité des correctifs
    • Le fait de connaître l'éditeur d'un logiciel n'apporte souvent aucune garantie de correction en cas de découverte de vulnérabilité (voir n'importe quel contrat de licence...) ;
    • En revanche, le fait de disposer du code source d'une application vous laisse toujours la possibilité de la corriger ou de la faire corriger.
  • La pertinence des correctifs
    • Si un éditeur persiste à ne pas apporter de réponse appropriée (en qualité, en temps, voire de réponse tout court !) à une vulnérabilité et que vous ne voulez ou ne pouvez pas vous passer de l'application concernée, alors vous êtes coincé.

A mes yeux, ce dernier point, que j'ai eu l'occasion de rencontrer professionnellement, justifie à lui seul, de l'intérêt de disposer pleinement du code source des applications.

Un enjeu plus global

Par certains côtés, ce débat s'apparente à ce que l'on appelle dans notre jargon, la recherche d'une balle magique (« silver bullet ») pour terrasser définitivement les problèmes de sécurité informatique.

Face à l'accroissement constant de la complexité des logiciels, la disponibilité du code source n'empêchera jamais l'existence de vulnérabilités. Il est donc impératif de concevoir la sécurité comme un processus, dont les actions portant sur le logiciel ne peuvent constituer qu'un des maillons d'un enjeu plus global de maîtrise des risques21.

A cet égard, force est de constater que les deux principaux objets de ce débat, Linux et Windows, souffrent des mêmes problèmes de "fonctionnalitose galopante"16 22.

--
Hubert Tournier, le 3 mai 2004.
Manager ligne de services en sécurité informatique de la branche française d'un "big 5",
CISSP, CISM, British Standard 7799 Lead Auditor, CISA 23


  1. Simson Garfinkel, Open Source: How Secure?, 14 novembre 1999 [^]
  2. Laura Koetzle et al., Forrester Research, Is Linux More Secure Than Windows?, 19 mars 2004 [^]
  3. Noah Meyerhans et al., "Is Linux more secure than Windows ?" - Debian, Mandrakesoft, Red Hat and SUSE answer, 6 avril 2004 [^]
  4. CIGREF, Le phénomène Linux en entreprise, 2000 [^]
  5. Michel Sapin, CIGREF, Discours prononcé lors de l'Assemblée générale du CIGREF, 26 septembre 2001 [^]
  6. CLUSIF, Panorama de la Cyber-criminalité - Année 2003, 13 janvier 2004 [^]
  7. Eric S. Raymond, The Cathedral and the Bazaar, 21 mai 1997 [^]
  8. Nikolai Bezroukov, Open Source Software Development as a special type of Academic Research (Critique of Vulgar Raymondism), 12 octobre 1999 [^]
  9. Nikolai Bezroukov, A Second Look at the Cathedral and the Bazaar, 9 décembre 1999 [^]
  10. Ross Anderson, Toulouse 2002, Security in Open versus Closed Systems - The Dance of Boltzmann, Coase and Moore, juin 2002 [^]
  11. Antoine Crochet-Damais, JDN Solutions, Microsoft s'engage sur le chemin de l'Open Source, 7 avril 2004 [^]
  12. Microsoft, Release Notes for Windows XP contained in the Relnotes.htm File [^]
  13. Microsoft, Microsoft Shared Source Initiative Home Page [^]
  14. Ian Lynch et Andrew Craig, Hackers saw Microsoft source code, 30 octobre 2000 [^]
  15. Kuro5hin, We Are Morons: a quick look at the Win2k source, 16 février 2004 [^]
  16. Robert Lemos, Site to pool scrutiny of Linux security, 6 février 2002 [^]
  17. Hal Flynn, Why Sardonix failed, 4 février 2004 [^]
  18. Duncan Campbell, Microsoft offer to resolve questions about NSA_key, then put up a brick wall, 25 mai 2000 [^]
  19. Ken Thompson, ACM, Reflections on Trusting Trust, septembre 1995 [^]
  20. Marc J. Cox, ApacheCon 2002 Las Vegas, Apache Security Secrets: Revealed [^]
  21. Bruce Schneier, Cryptorhythms, The Process of Security, avril 2000 [^]
  22. Bill Joy, Microsoft's blind spot, 7 février 2002 [^]
  23. Il s'agit ici d'une énumération bassement intéressée plutôt que de mégalomanie débordante : voir, par exemple, ici pourquoi (au 7ème item) [^]

Si par hasard l'un des liens externes ne fonctionnait plus, tentez votre chance sur la machine à voyager dans le temps d'Internet !


[ Drapeau anglais English version | Informations légales | Ours | Manifeste | Charte | Nous contacter | Commenter cette page ]
[ Anneau FreeBSD | Liste des sites | Aller à : 5 précédents - précédent - au hasard - suivant - 5 suivants ]