Vous êtes hacker, programmeur, développeur de logiciels ou codeur ? Beaucoup d'entre nous font partie de l'une de ces catégories. Et, en tant qu'êtres humains intelligents, nous avons tendance à nous concentrer sur ce qui n’existe pas encore et non pas à réinventer ce qui a déjà été fait ailleurs. Cela nous laisse davantage de temps pour produire des éléments nouveaux, adaptés à nos besoins, et pour les fonctions de base nous profitons d’utiliser des éléments de logiciels déjà produits ailleurs. Plusieurs plateformes, basées sur le travail de hackers, programmeurs, développeurs et codeurs du monde entier, telles que Gitlab au CERN, Github dans le monde et Stack Overflow, pour n'en citer que trois, fournissent une grande variété de bibliothèques et de séquences de code pour des fonctionnalités déjà existantes. Pour les utiliser, il suffit de les télécharger ou de faire un copier coller. Mais que se passe-t-il si ces hackers, programmeurs, développeurs et codeurs passent du côté obscur ?

Les codes open source constituent une ressource précieuse, mais non dénuée de risques. Puisque tout un chacun peut écrire et partager des codes, il va de soi que certains codes présentent des vulnérabilités flagrantes en matière de sécurité. Celles-ci ne sont pas nécessairement introduites avec de mauvaises intentions, et le caractère ouvert du code source permet à n'importe qui de vérifier l'intégrité du code et de le corriger si nécessaire. Pourtant, il arrive que même la communauté open source ne parvienne pas à identifier des failles importantes, comme cela a été le cas pour « Heartbleed ». Cela signifie qu'utiliser ces bibliothèques de codes publiques peut comporter un risque. Et ce risque devient encore plus important si des tiers mal intentionnés trafiquent les librairies de logiciels, puis attendent simplement que des développeurs passent par là, téléchargent des éléments contaminés et intègrent ces codes dans leur logiciel. Le code est exécuté... et c'est la catastrophe ! Des entreprises ont déjà été mises en péril à cause de bibliothèques infectées ou de variantes de cette situation. Par exemple, une faille a été découverte dans le module de Python appelé « ssh-decorator », qui est distribué via « PyPi », un dépôt de logiciel pour le langage de programmation Python. Tous les identifiants de connexion du canal SSH ont été transmis à un tiers mal intentionné. Ou alors, certaines bibliothèques créées par des personnes mal intentionnées ont été nommées de façon à ce que leur nom puisse être confondu avec celui d'une bibliothèque véritable et largement utilisée, comme par exemple « crossenv ». La version fausse (« cross-env ») extorquait des variables d'environnement locales et peut-être aussi des identifiants. Pas moins de 39 autres bibliothèques jouant sur de telles similarités orthographiques ont été identifiées, puis détruites de « NCM », un gestionnaire de logiciels largement utilisé pour le langage de programmation JavaScript. Et il y a aussi les bibliothèques anciennes qui ne sont plus maintenues par personne mais continuent d'être utilisées. Dans cet exemple, les droits ont naïvement été transmis à un pirate, lequel a ensuite introduit des éléments de code infectés dans une bibliothèque qui jusque-là était propre...

L'intégration automatique d'éléments provenant de bibliothèques de logiciels externes, par exemple PyPi ou NCM, n'est donc pas sans risque ! Tout comme quand vous surfez sur le web, rappelez-vous : s'arrêter – réfléchir – ne pas cliquer (ou, dans le cas présent, ne pas importer). N'installez que des bibliothèques de logiciels ou des éléments issus de ces bibliothèques émanant de sources sûres. Et même alors, inspectez le code, soit manuellement (même si c'est laborieux), soit au moins avec un outil d'analyse statique de code. L'équipe de la sécurité informatique du CERN fournit plusieurs outils d'analyse statique de code prévus à cette fin. Envisagez également d'utiliser un gestionnaire de dépôts de logiciels centralisé tel que Sonatype Nexus ou Apache Maven. Le premier est mis à disposition par le département IT du CERN et utilisé pour le développement des systèmes de contrôle-commande des accélérateurs et pour les expériences ATLAS et CMS.

_________

Pour en savoir plus sur les incidents et les problèmes en matière de sécurité informatique au CERN, lisez notre rapport mensuel (en anglais). Si vous désirez avoir plus d’informations, poser des questions ou obtenir de l’aide, visitez notre site ou contactez-nous à l’adresse Computer.Security@cern.ch.