La sécurité façon libre
Dans la guerre entre le code libre et le code propriétaire, un des champs de bataille privilégié est celui de la sécurité des infrastructures et des logiciels. Le code ouvert, “open-source”, “libre” ou autre épithète, permettrait une meilleure sécurité par la vigilance et la participation d’une communauté plus large… chose qui a été remise en cause par des fiascos de sécurité récents.
1. Le logiciel libre, une valeur sûre pour la sécurité ?
La loi de Linus est un principe bien connu et souvent accepté par les acteurs du logiciel. Nommée d’après Linus Torvalds, créateur et père spirituel du système d’exploitation libre Linux, cette règle d’or stipule qu’un code ouvert (c’est-à-dire lisible par la communauté des gens qui l’utilisent) serait plus performant en terme de sécurité qu’un code propriétaire, car les bugs et les failles de sécurité seraient plus vite repérés et remontés par les utilisateurs, puis le code mis à jour pour y pallier. Et il n’y a qu’à regarder le taux de participation à des projets libres de grande envergure pour se convaincre de la part de vérité de cette loi : le fonctionnement vertueux du logiciel libre fait également qu’un logiciel utilisé par un nombre important d’utilisateur (et donc en position critique) sera la source d’une attention toute particulière, en raison du grand nombre d’utilisateur.
Et cette loi, les grands éditeurs de logiciel propriétaire l’ont bien compris. Ce n’est pas pour rien qu’on retrouve de manière quasi-systématique des composants “libres” dans des logiciels propriétaires, leurs auteurs ayant tout à fait mesuré l’avantage qu’ils avaient à utiliser ce code testé, approuvé, relu et réécrit maintes et maintes fois par une large communauté. D’autre part, Google a montré la voie vers la collaboration allant dans le sens inverse : AngularJS, un outil bien connu des développeurs web et créé à l’initiative de Google est publié… sous licence MIT, le code étant accessible par tout un chacun sur la plateforme Github.
2. Mais il y a un mais
Seulement voilà. Des attaques récentes sur des briques de logiciel libre largement utilisées ont montré les limites du fonctionnement transparent et ouvert, avec des impacts parfois dévastateurs. L’exemple qui a sans doute fait le plus de bruit est le “fiasco OpenSSL” d’avril 2014, aussi connu sous le nom de l’attaque tristement célèbre dont elle a été le vecteur et la victime : Heartbleed. La fameuse librairie de cryptographie, utilisée par un nombre immense de serveurs et de navigateurs partout dans le monde, est développée sous licence permissive. Une belle mise en pratique du principe de Kerkhoff, venu de la cryptographie militaire. Celui-ci affirme que la “sécurité par l’obscurité” d’un système est illusoire, et que celui-ci “n’exige pas le secret, et qu’il puisse sans inconvénient tomber entre les mains de l’ennemi”. Dans notre cas, la connaissance de l’algorithme de cryptographie ne rend pas pour autant le système déchiffrable, au contraire : le seul moyen de “casser” le chiffrement est d’en posséder la clé. En théorie.
Son code, qui s’exécutait avec des privilèges importants sur les machines concernées, contenait un bug permettant l’accès par un attaquant à des zones protégées de la mémoire par un attaquant. Deux tiers des serveurs web auraient été vulnérables à cette attaque, et des milliers d’identités auraient été usurpées sur des sites aussi modernes et communément utilisés qu’Instagram, Pinterest ou Gmail.
OpenSSL est un exemple type de logiciel critique qui aurait dû être exempt de fautes, de part sa communauté d’utilisateurs. Mais au lieu de ça, cet épisode nous démontre une faille dans la loi de Linus, et cette faille est organisationnelle. L’OSF (OpenSSL Software Fundation) souffrait à l’époque de l’attaque Heartbleed d’un manque flagrant de personnel, et comptait quasiment exclusivement sur les contributions bénévoles d’un petit nombre de développeurs. La librairie était en quelques sortes “passée entre les mailles du filet” de la sécurité open-source.
Les structure derrière les logiciels open source ne sont pas exemptes de problèmes internes, qu’ils soient humains ou bassement financiers. Aucune ne l’est. Pas si grave : il n’y a qu’à voir le nombre d’organisations produisant des logiciels libres et open source et possédant une base de salarié et de financement adaptée à leurs ambitions pour se convaincre qu’il est possible d’éditer du code libre dans de bonnes conditions.
Pour autant les grands éditeurs de logiciels “privateurs” ont des outils pour pallier aux failles de sécurité dont les communautés “grassroots” ne disposent pas. Prenons l’exemple très actuel des attaques supply chain pour illustrer ce propos. Ces attaques consistent généralement à injecter du code malveillant dans un des composants du produit final en veillant à le présenter comme du code légitime. Cela revient le plus souvent à se procurer et utiliser un certificat légitime permettant de signer le code malicieux. De nombreux cas ont montré que les entreprises sont sensibles à ce type d’attaque en raison de la confiance qu’elles doivent accorder à leur fournisseurs et aux sous-traitant ayant accès au code : l’attaque sur les mises à jour ASUS de mars 2019 de par exemple, ou encore sur CCleaner. Tout l’enjeu réside dans la validation du code : tous les cas d’attaque supply chain auraient pu être évités si le code malicieux avait été relu par un pair du développeur en dépit de la signature valide. Facile à dire, et à priori rien ne garantie que les entreprises soient plus à même de réaliser cela que les projets communautaires, dont les plus importants surveillent de si près les nouveaux commit qu’il devient très exigeant de participer au développement. Mais l’avantage d’une organisation d’entreprise est de pouvoir valider en amont qui a accès au code, par exemple en s’assurant que la personne a bien été formé à la politique de sécurité de l’organisme, ou encore que son passif de développeur est sans tâche. Méthode excluante et nécessairement incompatible avec les principes du logiciel libre, mais qui permet un contrôle plus strict sur le code source.
3. Dans la pratique…
Si on considère des entreprises comme Microsoft ou Google, qui disposent de centaines voire de milliers d’ingénieurs dédiés à la sécurisation de leur logiciels propriétaires, la sécurité sera souvent meilleure que celle du logiciel libre. Par contre, si on considère une petite entreprise privée qui fait du logiciel propriétaire, son code sera généralement moins sécurisé que du code libre parce qu’elle n’aura clairement pas les moyens suffisants pour rivaliser avec la sécurité du libre, voire la dépasser. En pratique, la réalité est donc bien plus complexe. Le logiciel libre, de par la façon dont il est distribué, aura tendance à homogénéiser la sécurité. Il ne dépassera peut-être pas les leaders du code propriétaire, mais sera néanmoins une bien meilleure alternative au code propriétaire de l’écrasante majorité des entreprises aux moyens insuffisants.
Qu’est-ce qui, dans sa manière d’être distribué rend le libre plus homogène en termes de sécurité ?
Le code propriétaire intègre en fait beaucoup de code libre : 99% des nouveaux projets logiciels s’appuient sur du code libre selon Justin Hutchings. Pourquoi réinventer la roue, quand on peut bénéficier d’un code lu et relu, testé et approuvé par une grande communauté ? Dans le cas d’un logiciel propriétaire, dans un soucis de protection du code source, toutes les librairies et dépendances seront intégrées dans le package d’installation sous forme de binaire. Dans le cas d’un logiciel libre, elles seront téléchargées au moment de l’installation directement auprès de leur source.
Ainsi, si une vulnérabilité est détectée dans l’une des librairies en dépendance et qu’un patch de sécurité est développé, les utilisateurs de Linux bénéficieront de la mise à jour de la librairie dès que celle-ci sera disponible, tandis que les utilisateurs de Windows ou Mac devront attendre que les créateurs du logiciel téléchargé soient mis au courant de la vulnérabilité, fassent un nouveau package avec le binaire de la librairie mise à jour, et sortent la mise à jour de leur application. Si l’application est très suivie par ses créateurs, pas de problème : la mise à jour sortira suffisamment vite. Encore faut-il que l’utilisateur mette à jour son application. Par contre, si comme beaucoup d’entre elles l’application n’est plus suivie par ses créateurs, il n’y aura jamais de mise à jour et la faille de sécurité restera à jamais présente, prête à être exploitée. Quand beaucoup de problèmes de sécurité sont dus au fait que les utilisateurs ne mettent pas à jour leurs applications ou que les mises à jour ne sortent même plus, Linux propose d’automatiser la mise à jour des dépendances et ainsi homogénéiser la sécurité globale de ses utilisateurs.
Un autre atout de Linux sont les protections plus génériques qui sont proposées. Les vulnérabilités buffer overflow, Spectre et Meltdown par exemple ont été corrigées au niveau des compilateurs. Ainsi, le code des applications libres étant disponible directement sur internet, il suffisait de recompiler ce code avec un compilateur à jour pour obtenir un binaire exempt de ces vulnérabilités. Par contre, dans le cas du code propriétaire ce sont les binaires qui étaient disponibles librement, mais pas le code source. Il a donc fallu attendre que les créateurs des applications recompilent leur code avec les nouveaux compilateurs pour se débarrasser de ces vulnérabilités. Encore une fois si les créateurs suivent peu ou plus les vulnérabilités, les mises à jour tardent à venir. Dans l’ensemble le code libre permet donc plus de réactivité que le code propriétaire pour pallier les failles de sécurités : c’est une thèse soutenue par Ben Halter, Senior Product Manager en sécurité chez GitHub ainsi que Hervé Lemaitre, CTO chez Red Hat.
Pour finir, si le libre dispose généralement de plus d’yeux que le code, il dispose aussi de plus d’outils généralisés. GitHub propose désormais des alertes automatiques pour les développeurs quand leur code intègre une ou plusieurs librairies touchées par une vulnérabilité. Ceux-ci peuvent donc réagir plus vite, trouver une alternative à ces librairies ou installer un patch disponible et ainsi sécuriser leur code. Si une entreprise fait du code propriétaire en privé sur GitHub, elle bénéficiera probablement aussi de cette fonctionnalité. Mais si elle utilise un autre logiciel, il faudra qua largement diffusé les grands principes de transparence du code sont aujourd’hui elle implémente cette fonctionnalité elle-même. Et si elle n’en a pas les ressources ou si cela ne s’intègre pas dans sa politique, elle ne le fera pas. Le code libre bénéficie également du projet OSS-Fuzz de Google, qui consiste à mettre à l’épreuve un grand nombre de logiciels libres en injectant en entrée de nombreuses données aléatoires. Si le programme plante, alors il y a des défauts à corriger, et le développeur est notifié. Ce projet permet de faire progresser la le code l’est.communauté du libre et n’est évidemment disponible que si le code l’est.
Conclusion
Les méthodes de développement et les communautés entourant les briques de logiciels propriétaires et libres divergent fortement. Si la tentation de la “sécurité par l’obscurité” du logiciel propriétaire a depuis longtemps prouvé son inefficacité, la grande force en terme de sécurité informatique des entreprises adoptant ce mode de distribution reste dans leur organisation durable et dans les moyens importants qu’elles sont prêtes à investir dans les spécifications de sécurité. Mais cela est uniquement réservé aux plus importantes d’entre elles. Les principes du logiciel libre et open-source, malgré quelques épisodes ayant mis en doute la capacité des communautés à s’impliquer de manière pérenne dans le développement de logiciel (fiascos Heartbleed et Debian/OpenSSL), ont été largement adoptés. Leurs forces (repérage rapide des failles, déploiement automatiques de mises à jour…) sont telles que ces méthodes ont colonisé jusqu’au monde des éditeurs de logiciels.
Loïc Garnier, Théophile Lemarié.
