Leçons tirées des vulnérabilités d’OpenSSL — partie 1 : préparer votre chaîne d’approvisionnement à la prochaine vulnérabilité critique

C’est tôt le matin, un mardi d’octobre exceptionnellement doux. Vous consultez vos e-mails en savourant votre première tasse de café ou de thé de la journée, lorsque vous manquez de vous étouffer en lisant qu’OpenSSL va publier une mise à jour pour corriger une vulnérabilité CRITIQUE. Immédiatement, Heartbleed vous revient en tête. Vous rédigez rapidement un message Slack à votre responsable, puis, juste avant de cliquer sur « Envoyer », vous réalisez que vous savez exactement ce qu’il va vous demander : sommes-nous concernés, et comment allons-nous corriger le problème ?

L’équipe du projet OpenSSL a donné environ une semaine d’avertissement avant la vulnérabilité, de quoi semer la panique. Lorsqu’elle a finalement publié les correctifs de la version 3.0.7, elle a revu à la baisse le niveau de gravité, désormais élevé, et signalé deux nouvelles vulnérabilités. Mais si celle-ci avait été le prochain Heartbleed ? Auriez-vous été prêts ? Comment sauriez-vous si vous êtes concernés, et où ? Où faudrait-il chercher ? Après tout, ce n’est pas une question de savoir « si » une nouvelle vulnérabilité critique apparaîtra dans une bibliothèque couramment utilisée, mais « quand ». 

Dans cette série en deux parties, nous passerons en revue les éléments à prendre en compte pour repérer les occurrences d’une vulnérabilité dans votre chaîne d’approvisionnement logicielle. Nous nous intéresserons à OpenSSL et aux bibliothèques associées, mais aussi aux vulnérabilités de manière plus générale. Commençons par voir où chercher les bibliothèques vulnérables, puis quelques conseils et astuces de recherche.

Où chercher les bibliothèques vulnérables dans votre chaîne d’approvisionnement

Les deux nouveaux CVE d’OpenSSL (CVE-2022-3602 et CVE-2022-3786) sont des problèmes de dépassement de tampon qui affectent les versions 3.0.0 à 3.0.6 d’OpenSSL. Heureusement, les versions 1.x, bien plus répandues, n’étaient pas concernées. « Super, vous pensez-vous, il me suffit de vérifier si OpenSSL v3 est installé sur mes hôtes. » C’est un bon début, mais il y a d’autres éléments à prendre en compte et de nombreux endroits (et moyens) par lesquels des versions vulnérables pourraient se dissimuler.

Hôtes, machines virtuelles et images de conteneur

Les ressources utilisées pour exécuter vos charges de travail ne sont généralement pas considérées comme faisant partie de la chaîne d’approvisionnement, mais ne les négligez pas. En plus de vérifier que vos hôtes physiques — serveurs, ordinateurs de bureau, portables et stations de travail — n’exécutent pas de versions vulnérables d’OpenSSL, vous devez également tenir compte des hôtes virtuels. Il peut s’agir de machines virtuelles (VM) exécutées sur vos propres hyperviseurs, mais aussi d’instances de calcul sur AWS, GCP, Azure ou tout autre fournisseur cloud. Ces instances cloud, qu’il s’agisse d’EC2, de GCE ou d’un autre acronyme de marque, sont autant de points d’exploitation potentiels. De bonnes configurations cloud et réseau peuvent limiter l’accès à ces instances, mais mieux vaut tenir à jour un inventaire consultable. Pour ce faire, vous pouvez installer une solution de protection des terminaux sur vos hôtes ou utiliser des outils cloud natifs comme AWS Inspector (qui détecte les charges de travail AWS dans l’environnement AWS, sur EC2). Dans cet article, nous nous concentrerons sur le volet logiciel.

En plus d’exploiter des hôtes physiques et virtuels, plus de 90 % des organisations que nous avons interrogées exécutent également des charges de travail conteneurisées et serverless dynamiques et éphémères, qui peuvent être un peu plus difficiles à analyser. Ces charges de travail sont éphémères, car leur durée de vie peut être courte, et dynamiques, car elles peuvent être instanciées selon un calendrier ou en réponse à des événements déclencheurs. Vous ne pouvez donc pas vous contenter d’examiner les conteneurs en cours d’exécution : vous devez aussi vérifier les images de conteneur de votre inventaire, qui peuvent se compter par centaines, voire par milliers. 

Les images de conteneur sont généralement stockées dans un registre de conteneurs, tel que Docker Hub, Quay ou JFrog Artifactory, ou dans un dépôt d’images fourni par votre fournisseur cloud. En outre, les images peuvent être déployées comme charges de travail ou servir de fondation — ou d’image de base — à d’autres images. Les vulnérabilités sont souvent transitives. Si vous détectez une instance d’un package vulnérable dans une image de conteneur, il est possible, voire probable, que toutes les images dérivées créées à partir de cette image avec `FROM` soient également concernées.

Vous avez maintenant une bonne idée des endroits où rechercher OpenSSL sur vos hôtes (physiques, virtuels et éphémères). OpenSSL a probablement été installé à ces endroits via des gestionnaires de packages — par exemple avec `brew (or yum, or apt) install openssl` — ou à partir de packages téléchargés et installés manuellement. Il existe toutefois d’autres moyens pour que des packages vulnérables se retrouvent sur vos systèmes.

Code source et dépendances

Vous avez peut-être installé des versions précises d’OpenSSL sur vos hôtes, par exemple pour pouvoir vous connecter en SSH à d’autres hôtes ou depuis ceux-ci. Que ces occurrences de premier niveau soient vulnérables ou non, il peut y avoir des instances supplémentaires installées par le logiciel que vous utilisez, ou en parallèle de celui-ci, ainsi que par les logiciels que vous développez et déployez. Ces instances s’infiltrent dans votre chaîne d’approvisionnement lorsque votre code dépend directement des bibliothèques OpenSSL. Par exemple, si votre application déclare des bibliothèques OpenSSL dans ses dépendances, comme dans `requirements.txt`, `pom.xml` ou `Gemfile`. Cela peut aussi se produire si un élément de l’arbre de dépendances de votre application nécessite OpenSSL, même lorsque les dépendances transitives sont imbriquées sur de nombreux niveaux. Par exemple, votre application utilise une bibliothèque utilitaire qui dépend à son tour d’une bibliothèque de chiffrement, et ainsi de suite, jusqu’à ce que l’arbre de dépendances révèle que la bibliothèque « qux » a ajouté OpenSSL 3.05, alors qu’aucune des bibliothèques intermédiaires n’apparaît dans votre `Gemfile` de trois lignes. Si un élément de l’arbre de dépendances de votre application ajoute des bibliothèques OpenSSL, celles-ci figureront également dans la nomenclature logicielle (SBOM) de votre application.

Il arrive que les développeurs d’applications copient et distribuent directement les bibliothèques OpenSSL avec leurs applications, plutôt que de les intégrer via des gestionnaires de packages. Dans ce cas, la bibliothèque est intégrée à l’application lors du processus de compilation, au lieu de dépendre de la présence de bibliothèques externes.

Préparez-vous à la prochaine vulnérabilité de la chaîne d’approvisionnement avec Snyk

En utilisant Snyk Container et Snyk Open Source pour sécuriser votre chaîne d’approvisionnement logicielle, vous pouvez surveiller de façon proactive vos conteneurs et vos projets open source. Au lieu de devoir vous démener pour repérer les images de conteneur ou les packages open source vulnérables, vous pouvez savoir si vous êtes concernés avant même la publication des vulnérabilités. Vous aurez ainsi l’esprit tranquille : lorsque vous cliquerez sur l’icône « Envoyer » dans Slack pour transmettre votre message à votre responsable, vous connaîtrez déjà la réponse.

Si vous n’en avez pas encore, créez dès aujourd’hui un compte Snyk gratuit pour gagner du temps et simplifier vos recherches. Et revenez la semaine prochaine pour découvrir la suite de notre discussion sur la détection et la correction des vulnérabilités de la chaîne d’approvisionnement.