Skip to main content

Nouvelle vulnérabilité critique d’OpenSSL : ce qu’il faut savoir

wordpress-sync/feature-openssl

31 octobre 2022

0 minutes de lecture

Note de la rédaction : 1er novembre 2022

Snyk a contrôlé ses propres systèmes et outils pour vérifier s’ils utilisaient OpenSSL v3. Nous avons déterminé que les versions 4.127.0 à 4.134.0 de Snyk Broker utilisent une version vulnérable d’OpenSSL 3.0\. Par conséquent, une mise à jour vers la version 4.135.0 ou une version plus récente est nécessaire. Snyk Broker permet à nos clients d’intégrer à Snyk les plateformes SCM internes prises en charge.

Le 25 octobre 2022, le projet OpenSSLa annoncé la publication imminente d’une nouvelle version d’OpenSSL (la version 3.0.7) pour résoudre une faille de sécurité critique. Les vulnérabilités (il y en a en réalité 2) ont été dévoilées le 1er novembre 2022 et le projet a publié un article détaillant la nature des problèmes et les correctifs apportés. Un autre article de notre blog présente ces vulnérabilités et les raisons justifiant la réduction de leur gravité (d’abord critique, leur gravité a ensuite été jugée élevée). Le présent article explique quant à lui comment utiliser Snyk pour se préparer à ce type de vulnérabilité. Il a été mis à jour pour tenir compte des informations les plus récentes disponibles.

Snyk a publié un avis reprenant les informations connues à l’heure actuelle et le mettra à jour si de nouvelles informations voient le jour.

À propos de la vulnérabilité

Le projet OpenSSL a jugé cette vulnérabilité critique, mais affirme qu’elle ne concerne pas les versions d’OpenSSL antérieures à la version 3.0. Par conséquent, vous n’êtes a priori pas touché pour le moment si vous utilisez une telle version.

La politique de sécurité du projet OpenSSL explique quelles vulnérabilités sont considérées comme critiques :

Cette classification s’applique aux vulnérabilités qui concernent des configurations fréquentes et qui sont aussi susceptibles d’être exploitées. Exemples : divulgation importante du contenu de la mémoire d’un serveur (révélant potentiellement des informations utilisateurs), ou encore vulnérabilités pouvant être facilement exploitées à distance pour compromettre les clés privées d’un serveur ou pour lesquelles de l’exécution de code à distance est jugée probable dans de nombreuses situations classiques. Ces problèmes resteront confidentiels et entraîneront la publication d’une nouvelle version pour toutes les versions prises en charge. Nous tentons de les corriger aussi rapidement que possible.

Pour comprendre pourquoi le projet a finalement abaissé la gravité de la vulnérabilité à Critique, consultez cet article.

Les versions vulnérables d’OpenSSL (3.0 et supérieures) sont actuellement utilisées dans diverses distributions Linux, dont Ubuntu 22.04 LTS et RHEL 9. En revanche, les distributions comme Debian n’incluent que OpenSSL 3.x dans leurs versions les plus récentes, qui sont toujours considérées comme des versions de test. Par conséquent, leur utilisation dans les systèmes de production est potentiellement limitée. Les images de conteneurs créées à partir de versions de Linux vulnérables seront elles aussi concernées. Néanmoins, il convient de noter que beaucoup d’images Docker officielles populaires reposent sur Debian Bullseye (11) et Alpine, qui utilisent encore OpenSSL 1.x et ne sont donc pas concernées. Les images de conteneurs Docker officielles pour des projets comme nginx et httpd, des modules de gestion du trafic Web très utilisés, reposent aussi sur Bullseye et Alpine, et sont donc épargnées.

Node.js 18.x et 19.x utilisent aussi OpenSSL3 par défaut, et nous nous attendons à ce que des mises à jour de cette plateforme logicielle soient publiées dans les jours à venir.

Enfin, si vos développeurs codent en C/C++, ils intègrent peut-être des paquets OpenSSL v3. Vérifiez leur code pour déterminer si c’est le cas

Comment savoir si vous êtes concerné avant que les informations sur les vulnérabilités ne soient publiées

Ce qui est intéressant avec cette vulnérabilité, c’est que le projet OpenSSL a annoncé la disponibilité prochaine d’un correctif important une semaine à l’avance. Cette annonce précisait que la mise à jour corrigerait au moins une vulnérabilité critique, ce qui a laissé le temps de chercher quels applications, conteneurs et serveurs pouvaient être touchés. Une fois les informations sur les vulnérabilités publiées, les outils de sécurité tels que Snyk peuvent les détecter et fournir des correctifs. Mais avant cela, comment utiliser Snyk pour préparer un plan d’action ?

Les étapes qui suivent sont pensées pour la vulnérabilité d’OpenSSL, mais elles sont applicables à toute vulnérabilité dont les détails sont connus en amont, tant que vous disposez d’une nomenclature des logiciels et que vous effectuez une analyse SCA complète de tous les paquets du code source et des conteneurs.

Si vous disposez d’une formule Business ou Entreprise, vous pouvez localiser tous les projets incluant des versions vulnérables d’OpenSSL (3.0.x). Rendez-vous dans Reports, puis Dependencies. Dans la zone de recherche, saisissez openssl pour voir dans quels projets vous utilisez des versions de la branche 3.0.x. Le lien Projects vous permet d’accéder aux projets concernés. Vous pouvez également exporter les données vers un fichier CSV.

wordpress-sync/blog-openssl-critical-vuln-snykUI

Les clients ayant accès aux API Snyk (formules Business et Entreprise) peuvent utiliser l’API pour extraire cette donnée. Par exemple, vous pouvez vous servir de l’utilitaire fourni par l’équipe Snyk Labs, snyk-deps-to-csv, pour extraire les dépendances vers un fichier CSV. Vous pouvez également accéder à l’API des dépendances directement.

Tout utilisateur de Snyk peut, même avec un compte gratuit, rechercher une version vulnérable d’OpenSSL. Il doit pour se faire accéder au tableau de bord de Snyk, sélectionner un projet, cliquer sur l’onglet Dependencies et rechercher « openssl ». Répétons-le, seules les versions 3.0.x d’OpenSSL sont concernées.

wordpress-sync/blog-openssl-critcial-vuln-search

Si vous n’avez pas encore testé vos projets avec Snyk, vous pouvez le faire avec Snyk CLI :

  • Pour vérifier si vos projets de code contiennent des paquets open source comme OpenSSL ou des dépendances transitives utilisant OpenSSL, exécutez snyk test (résultats affichés directement dans la CLI) ou snyk monitor (résultats affichés dans l’interface Web de Snyk).

    • Si vous codez en C/C++ et souhaitez savoir si OpenSSL est inclus dans votre projet hors du cadre d’un gestionnaire de paquets (non géré) ajoutez l’option --unmanaged à la commande snyk test.

  • Pour tester des images de conteneurs, exécutez la commande snyk container test (résultats affichés directement dans la CLI) ou la commande snyk container monitor (résultats affichés dans l’interface Web de Snyk).

  • Pour les deux commandes test ci-dessus, vous pouvez afficher la liste des dépendances dans votre CLI en leur adjoignant l’option --print-deps. Si vous utilisez la commande monitor, les dépendances sont représentées automatiquement dans l’interface Web de Snyk.

  • Si vous utilisez Linux, vous pouvez vérifier la version d’OpenSSL utilisée en exécutant tout simplement la commande openssl version dans votre terminal :

wordpress-sync/blog-openssl-critical-vuln-cli

Comment limiter l’impact de cette nouvelle vulnérabilité d’OpenSSL

  1. Expliquez aux membres de votre équipe qu’une vulnérabilité a été découverte et qu’un correctif de sécurité sera publié le mardi 1er novembre 2022. Pour une préparation optimale, vous devez vous assurer que votre équipe est informée du problème.

  2. Évaluez vos applications et votre infrastructure pour déterminer si vous utilisez OpenSSL dans sa version 3.0 ou une version supérieure.

  3. Préparez-vous à mettre à jour les installations vulnérables d’OpenSSL dès le mardi 1er novembre 2022.

Si vous utilisez Snyk, sachez que cette faille sera intégrée à notre base de données dès que ses détails seront publics, le 1er novembre 2022. Vous serez alors invité à mettre à jour toutes les versions vulnérables détectées par Snyk dès que des correctifs seront disponibles.

Ne paniquez pas !

La gestion de vulnérabilités peut générer beaucoup de stress, mais il est inutile de sombrer dans la panique. Le projet OpenSSL a toujours géré les incidents de manière responsable et fourni rapidement des correctifs.

Si vous n’utilisez pas encore d’outil de détection comme Snyk, il est peut-être temps de vous y mettre. En effet, ils vous informeront de la survenue de ce type d’incident et peuvent aussi vous aider à déployer les correctifs de sécurité disponibles.

Il n’est malheureusement pas possible d’éviter tous les problèmes, mais rester informé des failles critiques et appliquer rapidement les corrections nécessaires permet véritablement de réduire les risques et de se protéger des violations.

Autres informations

Les ressources suivantes en lien avec cette vulnérabilité pourront vous aider à vous préparer :