REPUBLIQUE ET CANTON DE GENEVE

Département des constructions et des technologies de l'information

Centre des technologies de l'information

Logiciel libre et sécurité

Auteurs Patrick GENOUD, Observatoire technologiqueVersion / Date d’enregistrement V1.0 / 2007-04-05

Pour aller à l'essentiel

Observatoire technologiqueTéléphone +41 (22) 388 13 50 • Fax +41 (22) 388 13 57 • www.geneve.ch

Le logiciel libre a le potentiel pour être plus sûr que le logiciel propriétaire. Les projets open source peuvent en effet réaliser tout ce dont sont capables les projets réalisés en mode fermé, tout en bénéficiant des avantages liés à l'ouverture du code et au mode de développement communautaire. De nombreux projets open source de qualité supérieure sont là pour le prouver.

Mais il faut bien distinguer les potentialités indiscutables offertes par le modèle open source de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit réellement efficace dans le domaine de la sécurité, il faut ainsi que le projet réunisse une communauté suffisamment importante, dispose de développeurs sensibilisés et motivés par les questions de sécurité, revoie et corrige effectivement le code en terme de sécurité et dispose si possible de spécialistes en la matière.

Cela doit passer par une sensibilisation à la sécurité des communautés et de leur direction ainsi que par une industrialisation des processus de développement, en y intégrant étroitement la sécurité.

Logiciel libre et sécurité

Contexte

Dans le premier plan de mesures publié en novembre 2006 par le conseil d'État du canton de Genève, la promotion de l'utilisation de logiciels libres figure en bonne place (mesure n° 28). Le Centre des technologies de l'information (CTI) s'est engagé dans cette démarche avec une approche éloignée de tout dogmatisme.

Comme nous l'avons détaillé dans un précédent rapport1, l’intérêt du secteur public pour le logiciel libre est aujourd’hui indéniable, en particulier parce qu’il met très souvent en œuvre des standards ouverts, qu’il brise les positions de lock-in et qu’il permet une plus grand adaptabilité aux besoins particuliers. Les motivations essentielles avancées par les gouvernements sont une meilleure maîtrise et une pérennité accrue de leurs propres systèmes d’information, une plus grande neutralité dans le choix de vendeurs de solutions ainsi qu’une ouverture vers les entreprises et les citoyens désirant ou devant interagir avec les administrations.

Au delà de ces apports stratégiques indéniables, un nombre croissant de solutions open source gagnent en popularité en raison de leur excellentes performances, de leur fiabilité et de leur coût d'achat faible ou nul. La sécurité est également un domaine souvent mis en avant lorsque l'on évoque les avantages associés au logiciel libre. Cet aspect suscite de nombreuses controverses et les études qui y sont consacrées ne permettent pas d'apporter un point de vue définitif sur la question.

Le but de ce document est de porter un regard nuancé sur le lien entre sécurité et logiciel libre en se référant à l'avis de quelques experts dans le domaine.

Mais en préambule à toute considération relative aux aspects spécifiques liés à la sécurité, il n'est pas inutile de rappeler que le choix d'une solution informatique de devrait pas être conditionné par un seul critère particulier (comme la sécurité dans le cas qui nous intéresse), mais plutôt être envisagé de manière globale comme le suggère par exemple le référentiel NPT2.

La sécurité informatique est un vaste domaine et nous limiterons notre argumentaire aux aspects liés au développement d'applications en mode open source ou en mode fermé (par opposition au mode open source).

Dans ce document nous utiliserons de manière indifférente les termes de logiciel libre et de logiciel open source dont nous avons déjà précisé la définition ailleurs1.

Points de vue d'experts

L'expert en sécurité informatique David Wheeler3 propose dans un excellent document accessible en ligne un chapitre consacré à la relation entre open source et sécurité. Il y rappelle notamment le point de vue de plusieurs experts dans le domaine dont plusieurs sont cités ici. Cette revue n'a pas la prétention d'être exhaustive; elle illustre les principaux arguments énoncés lorsque l'on évoque le sujet.

Bruce Schneier4, expert en sécurité et en cryptographie, prétend que tout développeur devrait exiger de bâtir des solutions de sécurité sur des composants open source. La

1 Standards ouverts et logiciel libre Clarification des notions, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, 2005, http://ot.geneve.ch2 Référentiel Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technologique,Centre des technologies de l’information du canton de Genève, 2003, http://ot.geneve.ch3 Secure Programming for Linux and Unix HOWTO : Creating secure software, D. A. Wheeler, 2003, http://www.dwheeler.com/secure-programs4 Open Source and Security, B. Schneier, 1999, Crypto-Gram. Counterpane Internet Security, Inc., http://www.counterpane.com/crypto-gram-9909.html

- 2 -

Logiciel libre et sécurité

meilleure manière d'augmenter le niveau de qualité d'une solution est selon lui de permettre son examen par le plus grand nombre d'experts possible. Pour répondre à l'argument du secret souvent avancé par les défenseurs des logiciel fermés, Bruce Schneier insiste sur le fait que les composants open source sont conçus pour être sûrs malgré le fait qu'ils soient publics; c'est dans leur essence même.

Dans un article consacré au sujet Whitfield Diffie5, le co-inventeur de la cryptographie à clé publique, conclut en réponse aux arguments des adversaires de l'ouverture du code dans le domaine de la sécurité: « Il est simplement irréaliste de dépendre du secret en matière de sécurité des programmes informatiques. On peut prévenir la divulgation du mode de fonctionnement d'un programme, mais empêchera-t-on le code d'être désassemblé par des adversaires sérieux ? Probablement pas. ».

Vincent Rijmen6, l'un des développeurs de l'algorithme d'encryption AES (Advanced Encryption Standard) pense que la nature même du système d'exploitation open source Linux permet de mieux détecter et réparer les vulnérabilités de sécurité, non seulement parce que les gens ont accès au code, mais aussi et surtout parce que le modèle force les développeurs à adhérer à des standards et à produire du code plus clair, ce qui à son tour facilite la revue du code.

Mais Hissam et al7 relèvent le fait que l'accessibilité au code ne signifie pas nécessairement que celui-ci a été revu, notamment au niveau de la sécurité. Mais ils soulignent dans le même temps que c'est également le cas pour du code propriétaire.

Mais certains comme Fred Schneider8 ne croient pas que le logiciel libre contribue à la sécurité. Il n'y a selon lui pas de raison de penser que de nombreuses personnes inspectant un code ouvert soient forcément efficaces dans la détection de bugs liés à la sécurité. D'autre part, les bugs présents dans le code ne sont selon lui pas la cause majeure des attaques.

John Viega9 tempère ce point de vue en affirmant: « Les projets open source peuvent être plus sûrs que les projets dont le code est fermé. Cependant les aspects qui peuvent rendre un programme plus sûr – la disponibilité du code source et le fait qu'un grand nombre de personnes peuvent rechercher et réparer des trous de sécurité – peut aussi bercer les gens dans un faux sentiment de sécurité. ». Dans un article plus récent10, il considère que le logiciel libre a, sur le long terme, le potentiel pour être plus sûr que le logiciel propriétaire. Il se base sur le fait que les projets open source peuvent faire tout ce dont sont capables les projets commerciaux, tout en bénéficiant des avantages liés à l'ouverture du code. Mais cela doit passer par une sensibilisation à la sécurité des communautés et de leur direction ainsi que par une industrialisation des processus de développement, en y intégrant étroitement la sécurité. Les communautés open source devraient en outre reconnaître l'importance d'organismes d'audit indépendants.

David Wheeler11 insiste sur le fait qu'il n'est pas nécessaire d'avoir accès au code source d'un programme pour en découvrir les vulnérabilités, surtout lorsqu'on a uniquement l'intention de nuire. Il rappelle en outre que garder le secret au sujet d'une vulnérabilité ne la fera jamais disparaître et compare cette pratique à une bombe à retardement. La conclusion

5 Risky Business: Keeping Security a Secret, W. Diffie, 2003, ZDNet, http://news.zdnet.com/2100-9595_22-980938.html 6 LinuxSecurity.com Speaks With AES Winner, V. Rijmen, 2000, http://www.linuxsecurity.com/content/view/117552/49/ 7 Trust and Vulnerability in Open Source Software, S. A. Hissam, D. Plakosh et C. Weinstock, 2002, Software IEE-Proceedings,, Vol 149-1, p 47-51, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=999090 8 Open Source in Security: Visting the Bizarre, F. B. Schneider, 2000, Proceedings of the 2000 IEEE Symposium on Security and Privacy, May 14-17, 2000, Berkeley, CA. Los Alamitos, CA: IEEE Computer Society. pp.126-127.9 The Myth of Open Source Security, J. Viega, 2002, http://www.developer.com/tech/article.php/62185110 Open source security: still a myth, J. Viega, 2004, O'Reilly publisher (http://www.oreilly.com), http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html 11 Secure Programming for Linux and Unix HOWTO : Creating secure software, D. A. Wheeler, 2003, http://www.dwheeler.com/secure-programs

- 3 -

Logiciel libre et sécurité

de son argumentaire rejoint celle de John Viega: le fait de rendre un programme open source ne garantit pas une meilleure sécurité. Un processus de revue effective de code devrait être mis en place avec un regard particulier sur les questions relatives à la sécurité. De plus le projet devrait inclure des spécialistes qui savent comment concevoir, développer et examiner des programmes sûrs. Enfin un processus de correction des vulnérabilités et de distribution des patches de corrections devrait être mis en place.

Pour compléter ce tableau, mentionnons l'article de Alain Boulanger12 dans lequel l'auteur compare les modèles libre et propriétaire au niveau de la sécurité. Il y discute des aspects liés à la sécurité et à la fiabilité de ces modèles en examinant deux points clés: l'ouverture du code et le taux d'erreurs du logiciel. Boulanger réfute les arguments développés dans le livre blanc publié en 2002 par l'organisation Alexis de Tocqueville Institution13 (fondée en partie par Microsoft) et qui présente l'usage du logiciel libre dans les organismes gouvernementaux comme un risque de sécurité majeur en raison de la visibilité du code pour les pirates informatiques.

Outre les arguments déjà énoncés plus haut, Boulanger constate que les études recensant le nombre et la fréquence des rapports de vulnérabilités dans les logiciels parlent plutôt en faveur des logiciels libres que de leurs équivalents propriétaires, spécialement dans le cas de projets d'envergure comme GNU/Linux, Apache (serveurs Web) ou MySQL (bases de données). Comme plusieurs autres auteurs Boulanger conclut son article sans déclarer de vainqueur: les arguments analytiques favorisant l'une ou l'autre approche ne sont en effet pas concluants. Il est convaincu que les projets open source ayant atteint une masse critique suffisante produiront des résultats supérieurs à leurs équivalents propriétaires, et ceci à un moindre coût.

Pour résumer un sentiment largement partagé concernant le lien entre logiciel libre et sécurité nous terminerons avec la citation de Elias Levy, ancien modérateur de Bugtraq (l'un des forums de discussion majeurs consacrés à la sécurité), qui résume son point de vue sur la question ainsi: « Cela signifie-t-il que le logiciel libre n'est pas meilleur que le logiciel propriétaire en terme de sécurité ? La réponse est non. Le logiciel libre a certainement le potentiel d'être plus sûr que son son équivalent propriétaire. Mais ne vous y trompez pas, le simple fait d'être ouvert ne constitue pas une garantie de sécurité ».

Principaux arguments

Comme le propose un récent rapport du Gartner Group14 sur la question, on peut sommairement regrouper les bénéfices et les risques associés à l'ouverture du code source selon les quatre thèmes (très liés) développés ci-dessous. Chacun de ces thèmes fait référence à bon nombre d'arguments développés au chapitre précédent.

Une multitude de réviseursL'opinion selon laquelle le logiciel libre est fondamentalement plus sûr que son équivalent propriétaire s'appuie principalement sur l'une de ses qualités intrinsèques qu'est l'ouverture du code source à une large communauté. Cette dernière, qui peut compter plusieurs milliers de personnes dans certains projets, est capable de détecter et de corriger rapidement des problèmes éventuels, au niveau de la sécurité notamment. Mais ce n'est pas seulement la mutilitude des réviseurs qui fait la force du modèle open source; c'est surtout le mode de

12 Open-source versus proprietary software Is one more reliable and secure than the other?, A. Boulanger, 2005, IBM Systems Journal, http://findarticles.com/p/articles/mi_m0ISJ/is_2_44/ai_n14707716 13 Opening the Open Source Debate: A White Paper, Alexis de Tocqueville Institution, 2002, http://www.adti.net/ip/opensource.pdf 14 Open-Source and Closed-Source AD Security: Combining the Benefits of Both Paradigms, J. Feiman, Gartner Group 2006, http://www.gartner.com

- 4 -

Logiciel libre et sécurité

travail des communautés qui collaborent en réseau en incluant de manière active développeurs et utilisateurs de la solution.

Cet argument n'est cependant réellement valable que dans le cas où la communauté est nombreuse et qu'elle peut compter sur des développeurs expérimentés, sensibilisés et motivés par les questions relatives à la sécurité. Le fait de pouvoir s'appuyer sur des spécialistes dans le domaine de la sécurité est également essentiel, ne serait-ce que pour initier un projet sur de bonnes bases (architecture, méthodologie, etc.).

Comme le soulignent de nombreux spécialistes, il faut bien distinguer les potentialités indiscutables offertes par le modèle open source de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit effectivement efficace dans le domaine de la sécurité, il faut ainsi que le projet réponde à un minimum de critères:

réunir une communauté suffisamment importantedisposer de développeurs sensibilisés et motivés par les questions de sécuritérevoir et corriger effectivement le code en terme de sécuritédisposer si possible de spécialistes en la matière

Ouverture du code sourceLes éditeurs de logiciels propriétaires prétendent souvent que le fait de cacher le code source empêche les pirates potentiels d'exploiter les vulnérabilités d'un programme. Mais il n'est pas nécessaire d'avoir accès au code source pour cela. Il existe des outils permettant de désassembler les programmes ou de mettre en évidence des modèles de comportement lors de leur utilisation comme les programmes de type Web application security vulnerability scanners (WASVS) qui sont conçus pour détecter des vulnérabilités sans devoir accéder au code source. Certains d'entre eux sont d'ailleurs des logiciels libres.

De nombreux experts réfutent l'argument de la sécurité par l'obsucrité qui a notamment pour défaut de bercer les propriétaires d'une solution fermée dans l'illusion d'une fausse sécurité. Si le fait de cacher le code source peut avoir un sens lorsque l'on désire préserver un avantage concurrentiel, cela en a cependant peu, voir pas du tout en terme de sécurité.

L'ouverture du code source est à mettre directement en regard du point précédent. Elle ne porte ses fruits au niveau de la sécurité que si le projet est correctement engagé dans une démarche de révision prenant en compte la sécurité.

Certains experts affirment également que l'ouverture du code a un impact indirect sur la sécurité car elle pousse les développeurs à écrire du code plus lisible, ce qui contribue à améliorer la qualité du code, à facilite sa révision et à diminuer le nombre d'erreurs.

Détection précoce des problèmesDans le cas du logciel libre, lorsqu'un problème de sécurité est détecté, la communauté des développeurs et des utilisateurs en est très vite informée. Cela augmente les chances de résoudre rapidement le problème. Ce point est naturellement directement lié à l'ouverture du code, mais également au mode de fonctionnement des communautés du libre. La rapidité de réaction de la communauté dépend entre autres de la popularité et de la vitalité du projet.

Cet argument est très théorique. Il dépend d'une part de la taille de la communauté, de la popularité du projet, de la sensibilité des utilisateurs et des développeurs à la sécurité ainsi que de leur motivation à résoudre le problème soulevé. Mais il se trouve que dans de nombreux projets, c'est effectivement le cas, comme le détaille Alain Boulanger13.

- 5 -

Logiciel libre et sécurité

Méthodologies de développement L'un des arguments avancés lorsque l'on parle de sécurité logicielle est celui de la méthodologie de développement utilisée, que celle-ci soit générale (comme CMMI15 ou TST/PSP16) ou plus spécifique à la sécurité (comme SSE-CMM17 ou TST/PSP-secure18).

Selon le Gartner Group, l'usage de ces méthodologies influe directement sur le niveau de sécurité des solutions. Leur faible adoption par les projets open source peut être compensée par les compétences de la communauté, pour autant que cette dernière soit suffisamment importante, expérimentée et motivée à prendre en compte les aspects liés à la sécurité.

La sensibilisation des développeurs à de telles méthodologies ne peut qu'augmenter la qualité des projets open source de moindre envergure.

Conclusion

Le logiciel libre a le potentiel pour être plus sûr que le logiciel propriétaire. Les projets open source peuvent en effet réaliser tout ce dont sont capables les projets réalisés en mode fermé, tout en bénéficiant des avantages liés à l'ouverture du code et au mode de développement communautaire. De nombreux projets open source de qualité supérieure sont là pour le prouver.

Mais il faut bien distinguer les potentialités indiscutables offertes par le modèle open source de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit réellement efficace dans le domaine de la sécurité, il faut ainsi que le projet:

réunisse une communauté suffisamment importante,dispose de développeurs sensibilisés et motivés par les questions de sécurité,revoie et corrige effectivement le code en terme de sécurité et dispose si possible de spécialistes en la matière.

Cela doit passer par une sensibilisation à la sécurité des communautés et de leur direction ainsi que par une industrialisation des processus de développement, en y intégrant étroitement la sécurité.

15 Capability Maturity Model Integration : http://www.sei.cmu.edu/cmmi 16 Team Software Process (TSP) and the Personal Software Process (PSP) : http://www.sei.cmu.edu/tsp 17 Systems Security Engineering Capability Maturity Model : http://www.sse-cmm.org/index.html 18 TST/PSP-secure : http://www.sei.cmu.edu/tsp/tsp-security.html

- 6 -