Skip to main content

Comment le code C++ open source peut introduire des risques de sécurité

Écrit par
Headshot of Snyk Security Research Team

Snyk Security Research Team

feature plus plus

22 août 2022

0 minutes de lecture

Les bibliothèques et frameworks open source sont un excellent moyen de lancer rapidement des projets de développement. L’open source permet aux développeurs de réaliser de grandes choses sans réinventer la roue ni développer des solutions à des problèmes déjà résolus.

Cependant, l’ajout de code à un projet comporte toujours un risque inhérent d’introduire des vulnérabilités potentielles qui ont pu s’y glisser par erreur ou par malveillance.

Cet article explique comment le code open source introduit des vulnérabilités dans la chaîne d’approvisionnement logicielle. Il présente également des moyens d’identifier les vulnérabilités dans le code C++ open source à l’aide d’outils automatisés d’analyse des vulnérabilités.

Comment le code open source introduit des risques de sécurité

L’écosystème des logiciels open source est étroitement interconnecté. Lorsque vous installez un composant open source dans votre code, celui-ci s’accompagne de dépendances. Il est difficile de surveiller en permanence les problèmes de sécurité que chacune de ces dépendances peut présenter, et vous ne pouvez pas toujours compter sur les responsables des packages pour corriger ces vulnérabilités à temps. Il peut donc y avoir des vulnérabilités non corrigées dans les packages open source présents dans votre base de code.

Les données issues de recherches récentes menées par Snyk et la Linux Foundation montrent que le délai de correction des vulnérabilités dans les projets open source a régulièrement augmenté, passant de 49 jours en 2018 à 110 jours en 2021. La correction des vulnérabilités dans les projets open source prend presque 20 % plus de temps (18,75 %) que dans les projets propriétaires. Compte tenu de ces difficultés, les applications open source présentant des vulnérabilités connues sont des cibles de choix pour les pirates.

Les vulnérabilités de dépassement de tampon sont fréquentes dans les langages de programmation de bas niveau, comme C ou C++, car l’allocation de mémoire incombe aux développeurs. C et C++ ne protègent pas l’application contre les clients qui accèdent à des données au-delà des limites d’un tampon ou qui y écrivent des données, ce qui rend les projets C++ open source vulnérables. Dans les applications dont la mémoire est mal gérée, les pirates peuvent exploiter cette vulnérabilité pour insérer du code exécutable dans le programme.

Prenons par exemple le bogue Glibc découvert dans la bibliothèque libresolv de la GNU C Library. Ce bogue exposait Glibc à des attaques par dépassement de tampon lors de l’utilisation de la fonction de bibliothèque getaddrinfo.

Un pirate peut exploiter cette vulnérabilité en incitant un client à rechercher un domaine malveillant. Il peut alors renvoyer une charge utile qui déclenche le bogue. Si le client dispose des privilèges root, le système peut être compromis et faire l’objet d’une attaque de l’homme du milieu. Glibc est utilisé dans des millions de systèmes fonctionnant avec le noyau Linux ; tout système exécutant une version de Glibc contenant cette vulnérabilité peut donc être affecté.

Qu’est-ce qu’une chaîne d’approvisionnement logicielle ?

Le terme « chaîne d’approvisionnement » est traditionnellement employé dans le secteur manufacturier. Un constructeur automobile, par exemple, peut fabriquer certaines pièces en interne et en acheter d’autres auprès d’autres entreprises. Ainsi, avant qu’une voiture n’arrive à son propriétaire, de nombreuses personnes utilisant différents outils ont travaillé à sa fabrication.

Dans le domaine logiciel, la chaîne d’approvisionnement fonctionne de manière assez similaire. La chaîne d’approvisionnement logicielle désigne tout ce qui entre dans votre code ou interagit avec lui, du développement au déploiement. Elle comprend le code et les binaires, les développeurs qui ont travaillé sur le projet et les dépôts où il est déployé. Elle englobe également les outils de compilation, les scripts de packaging et l’infrastructure de l’application. La sécurité de la chaîne d’approvisionnement est essentielle.

La chaîne d’approvisionnement logicielle étant composée de nombreux éléments, elle peut devenir très complexe. Les pirates aiment exploiter cette complexité.

Les vulnérabilités de la chaîne d’approvisionnement logicielle

Lors d’une attaque contre la chaîne d’approvisionnement logicielle, des acteurs malveillants exploitent les composants en amont liés à leur cible pour obtenir un accès. Ils peuvent également s’en prendre aux services qui distribuent ou exécutent le logiciel. Dans ce cas, ces composants en amont ne sont pas nécessairement la cible de l’attaque : ils servent uniquement de moyen d’accès.

Les trois principales cibles d’une attaque contre la chaîne d’approvisionnement sont les dépendances, les pipelines et les dépendances des pipelines.

Dépendances

Les pirates ciblent les dépendances open source que les développeurs intègrent lors de la création d’applications. Si un pirate introduit un logiciel malveillant dans un package open source courant en exploitant une vulnérabilité connue, les applications qui l’installent comme dépendance sont exposées. Comme les applications peuvent avoir plusieurs dépendances contenant elles-mêmes d’autres dépendances, il est difficile de suivre les vulnérabilités potentielles. Les dépendances constituent donc des cibles faciles.

Pipelines

Lors d’une attaque visant un pipeline, des utilisateurs malveillants ciblent le pipeline d’intégration et de déploiement continus (CI/CD), qui offre une vaste surface d’attaque. Il peut accéder aux configurations par défaut, aux identifiants de sécurité, aux bases de données et au code propriétaire. Par conséquent, lorsqu’un pirate insère du code malveillant dans un pipeline CI/CD et le compromet, il peut créer une porte dérobée dans les applications qui l’utilisent.

Dépendances des pipelines

Les pirates peuvent également cibler les dépendances des pipelines pour accéder à un environnement de compilation. Par exemple, lors de la violation de Codecov, les acteurs malveillants ont utilisé les identifiants d’une image Docker pour modifier un script Bash d’envoi. Ils ont modifié le script afin de s’envoyer les variables d’environnement des utilisateurs de Codecov.

Identifier les vulnérabilités dans les dépendances open source

Même si le code open source peut présenter ses propres problèmes, il permet toujours aux développeurs de réaliser des choses extraordinaires et de s’appuyer sur le travail d’autres personnes. Mais les développeurs doivent pouvoir identifier les vulnérabilités et évaluer la qualité du code open source utilisé dans leurs projets. Or, la plupart des organisations ne peuvent pas mobiliser les ressources nécessaires pour examiner manuellement le code et auditer le code open source avant de l’utiliser.

Il serait difficile de détecter les vulnérabilités telles que les dépassements de tampon, les pointeurs nuls, les dépassements et les sous-dépassements d’entiers, entre autres, dans chaque dépendance C/C++ de la chaîne d’approvisionnement. Par exemple, une vulnérabilité liée à un pointeur nul dans un morceau de code C/C++ open source utilisé dans notre chaîne d’approvisionnement logicielle peut être exploitée par des pirates et provoquer un plantage. Peu importe que le code de l’application ne présente aucune vulnérabilité : celles du code open source suffisent à la rendre non sécurisée.

Il existe deux méthodes principales pour identifier les vulnérabilités des dépendances open source : créer une chaîne d’approvisionnement logicielle sécurisée, où chaque étape est confiée à un contributeur de confiance, et utiliser des outils automatisés d’analyse des vulnérabilités, comme Snyk pour C/C++.

Créer une chaîne d’approvisionnement logicielle sécurisée

En théorie, suivre chaque contributeur de la chaîne d’approvisionnement et s’assurer de sa fiabilité est une bonne solution, mais sa mise en œuvre est extrêmement difficile. La chaîne d’approvisionnement logicielle comprend de nombreux développeurs responsables de différentes bibliothèques et de différents composants utilisés dans une application.

Outils automatisés d’analyse des vulnérabilités, comme Snyk pour C/C++

Une solution plus pratique consiste à analyser le code open source pour y détecter les vulnérabilités de sécurité. Toutefois, effectuer ces analyses manuellement peut prendre du temps et être source d’erreurs. La bonne pratique consiste à analyser le code C++ open source à l’aide d’un outil automatisé d’analyse des vulnérabilités, comme Snyk.

Avec Snyk Open Source, les développeurs bénéficient d’une visibilité sur le code C++ open source qu’ils utilisent. La CLI Snyk convertit les fichiers en signatures numériques, ou hachages, qui sont ensuite comparés aux bases de données de Snyk afin d’établir une liste des composants open source correspondants. Les développeurs peuvent détecter les vulnérabilités en comparant cette liste à la Snyk Vulnerability Database.

Contrairement à d’autres outils d’analyse des vulnérabilités qui examinent les fichiers individuellement, Snyk tient compte de leur contexte. En s’appuyant sur des fichiers auxiliaires, comme les fichiers readme et les scripts d’installation, Snyk réduit le nombre de rapports de vulnérabilités faussement positifs. Cela réduit le bruit et aide les développeurs à se concentrer sur les corrections nécessaires.

Dès qu’une vulnérabilité est détectée, Snyk en informe les développeurs dans leur IDE ou leur CLI et identifie automatiquement la mise à niveau minimale nécessaire pour la corriger sans rompre le reste du code.

Conclusion

La popularité des logiciels open source ne cesse de croître. De plus en plus d’applications intègrent donc des bibliothèques et des composants tiers, écrits et maintenus par des personnes inconnues. Ces bibliothèques étant accessibles dans des dépôts publics, les pirates peuvent exploiter celles qui sont les moins sécurisées pour obtenir un accès.

Pour éviter les vulnérabilités lorsque vous utilisez du code open source dans des projets C++, servez-vous d’un outil automatisé d’analyse des vulnérabilités comme Snyk Open Source. Vous pouvez ainsi analyser les projets C++ open source de votre application, détecter les bibliothèques malveillantes et protéger vos logiciels contre toute compromission.

Consultez la documentation Snyk pour C/C++ pour découvrir comment analyser vos projets C/C++.

Lancez-vous dans les compétitions Capture The Flag

Apprenez à résoudre des défis de capture du drapeau en regardant à la demande notre atelier virtuel d’initiation.