Skip to main content

Nouvelle vulnérabilité critique dans OpenSSL : ce que vous devez savoir

feature openssl

31 octobre 2022

0 minutes de lecture

Note de la rédaction : 1er novembre 2022

Snyk a vérifié si ses propres systèmes et outils utilisaient OpenSSL v3. Nous avons constaté que Snyk Broker, dans ses versions 4.127.0 à 4.134.0, utilise une version affectée d’OpenSSL 3.0 et doit être mis à niveau vers la version 4.135.0 ou ultérieure. Snyk Broker permet aux clients d’intégrer à Snyk les plateformes SCM internes prises en charge.

Le 25 octobre 2022, le projet OpenSSL a annoncé la sortie prochaine d’OpenSSL (version 3.0.7) afin de corriger une vulnérabilité de sécurité critique. Les vulnérabilités (il y en avait deux, et non une seule) ont été rendues publiques le mardi 1er novembre 2022 et le projet OpenSSL a publié un article de blog détaillant les problèmes et les correctifs. Dans un autre article, Snyk examine les vulnérabilités et explique pourquoi leur gravité a été abaissée de critique à élevée. Cet article explique comment utiliser Snyk pour se préparer à des vulnérabilités comme celle-ci. Il a été mis à jour en fonction des dernières informations.

Snyk a publié un avis contenant les informations actuellement connues et le mettra à jour si de nouveaux détails sont rendus publics.

À propos de la vulnérabilité

Le projet OpenSSL a qualifié cette vulnérabilité de critique, mais a précisé qu’elle ne toucherait pas les versions d’OpenSSL antérieures à la version 3.0. Par conséquent, si vous utilisez une version d’OpenSSL antérieure à la 3.0, vous ne devriez pas être concerné pour le moment.

La politique de sécurité du projet OpenSSL définit ce qu’il considère comme des vulnérabilités critiques :

Cela concerne les configurations courantes, qui sont également susceptibles d’être exploitées. Parmi les exemples figurent la divulgation importante du contenu de la mémoire du serveur (pouvant révéler des informations sur les utilisateurs), les vulnérabilités facilement exploitables à distance pour compromettre les clés privées d’un serveur, ou encore les cas où une exécution de code à distance est jugée probable dans des situations courantes. Ces problèmes resteront confidentiels et entraîneront la publication d’une nouvelle version de toutes les versions prises en charge. Nous nous efforcerons de les corriger au plus vite.

Pour en savoir plus sur les raisons de la décision d’abaisser la gravité à élevée, consultez l’article de blog d’OpenSSL.

Les versions vulnérables d’OpenSSL (3.0 et ultérieures) sont actuellement utilisées dans des systèmes d’exploitation Linux, notamment Ubuntu 22.04 LTS, RHEL 9 et d’autres. Toutefois, les distributions Linux comme Debian n’intègrent OpenSSL 3.x que dans leurs versions les plus récentes, qui sont encore considérées comme des versions de test ; leur utilisation à grande échelle dans les systèmes de production pourrait donc être limitée. Les images de conteneurs basées sur des versions vulnérables de Linux sont également concernées. Il convient toutefois de noter que de nombreuses images Docker Official populaires utilisent Debian Bullseye (11) et Alpine, qui utilisent encore OpenSSL 1.x et ne sont pas concernées. Les images de conteneurs Docker Official de projets comme nginx et httpd, couramment utilisés pour gérer le trafic Web, sont également basées sur Bullseye et Alpine et ne sont donc pas concernées.

Node.js 18.x et 19.x utilisent également OpenSSL 3 par défaut. Nous prévoyons donc des mises à niveau de Node.js dans les prochains jours.

Enfin, si vos développeurs utilisent C/C++, ils peuvent intégrer des packages OpenSSL v3 à leur code. Vous devriez vérifier si ce code contient les packages OpenSSL concernés.

Comment savoir si vous êtes concerné avant la publication des vulnérabilités

L’un des aspects intéressants de cette vulnérabilité est que le projet OpenSSL a annoncé une semaine à l’avance qu’un correctif de sécurité important allait être publié. Comme il avait été indiqué qu’il y aurait au moins une vulnérabilité critique, les équipes ont eu le temps de rechercher les applications, conteneurs et serveurs potentiellement concernés. Une fois les vulnérabilités publiées, les outils de sécurité comme Snyk détectent naturellement leur présence et proposent des correctifs. Mais avant leur publication, comment utiliser Snyk pour élaborer un plan d’action ?

Les étapes ci-dessous concernent cette vulnérabilité OpenSSL. Vous pouvez toutefois les appliquer à toute vulnérabilité dont les détails sont connus à l’avance, à condition de disposer d’une nomenclature logicielle et d’effectuer une analyse SCA complète de tous vos packages open source et conteneurs.

Si vous êtes client Snyk avec un forfait Business ou Enterprise, vous pouvez trouver tous les projets qui incluent des versions vulnérables d’OpenSSL (3.0.x). Accédez à Rapports, puis à Dépendances. Dans la zone de recherche, saisissez openssl pour repérer les endroits où vous utilisez peut-être des versions 3.0.x. Le lien Projets vous mène aux projets concernés. Vous pouvez aussi exporter les données au format CSV.

Vue des dépendances de Snyk Reports filtrée sur « openssl », présentant les versions vulnérables, les projets concernés et un bouton Exporter au format CSV.

Les clients ayant accès aux API Snyk (forfaits Business et Enterprise) peuvent également utiliser l’API pour extraire ces données. Par exemple, vous pouvez utiliser un outil fourni par l’équipe Snyk Labs, appelé snyk-deps-to-csv, pour exporter les dépendances au format CSV. Vous pouvez également accéder directement à l’API des dépendances.

Tous les utilisateurs de Snyk, y compris ceux qui ont un compte gratuit, peuvent rechercher une version vulnérable d’OpenSSL dans le tableau de bord Snyk : sélectionnez un projet, cliquez sur l’onglet Dependencies, puis recherchez « openssl ». Là encore, les versions concernées sont celles d’OpenSSL 3.0.x.

Tableau de bord des dépendances filtré sur « openssl », affichant les packages liés à OpenSSL et le nombre de problèmes critiques, élevés, moyens et faibles.

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

  • Pour tester vos projets de code à la recherche de packages open source comme OpenSSL ou de dépendances transitives qui utilisent OpenSSL, exécutez snyk test pour afficher les résultats directement dans votre CLI, ou snyk monitor pour les consulter dans l’interface Web de Snyk.

    • Si vous utilisez C/C++ et souhaitez savoir si OpenSSL est inclus dans votre projet en dehors d’un gestionnaire de packages (dépendance non gérée), ajoutez l’option --unmanaged lorsque vous exécutez snyk test.

  • Pour tester des images de conteneurs, exécutez snyk container test pour afficher les résultats directement dans votre CLI, ou snyk container monitor pour les envoyer à l’interface Web de Snyk.

  • Pour afficher la liste des dépendances dans votre CLI avec l’un ou l’autre des types de test ci-dessus, ajoutez l’option --print-deps. Si vous utilisez la commande monitor, les dépendances sont automatiquement répertoriées dans l’interface Web de Snyk.

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

Terminal affichant la commande « openssl version » et le résultat « OpenSSL 1.1.1l 24 août 2021 »

Comment atténuer la nouvelle vulnérabilité OpenSSL

  1. Informez votre équipe de l’annonce de la vulnérabilité et de la prochaine mise à jour de sécurité, prévue pour le mardi 1er novembre 2022. Le meilleur moyen de vous préparer est de vous assurer que votre équipe est au courant du problème et de la sortie prochaine de la mise à jour.

  2. Évaluez vos applications et votre infrastructure pour déterminer si vous utilisez OpenSSL 3.0 ou une version ultérieure, où que ce soit.

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

Si vous utilisez Snyk pour détecter et corriger les vulnérabilités, nous ajouterons celle-ci à notre base de données et la détecterons lorsque vous analyserez vos projets, le 1er novembre 2022, une fois les détails rendus publics. Vous serez invité à mettre à jour toutes les versions vulnérables suivies par Snyk dès que des correctifs seront disponibles.

Pas de panique !

La gestion des vulnérabilités critiques peut être stressante, mais pas de panique ! Le projet OpenSSL a fait ses preuves depuis longtemps en matière de gestion responsable des incidents de sécurité et de publication rapide de correctifs.

Si vous n’utilisez pas encore un outil de détection des vulnérabilités comme Snyk, le moment est peut-être bien choisi pour en essayer un. Ces outils vous aident à être informé des incidents de ce type lorsqu’ils surviennent et peuvent même vous aider à déployer des correctifs de sécurité dès qu’ils sont disponibles.

Il est impossible de corriger tous les problèmes. Toutefois, en surveillant les vulnérabilités critiques et en effectuant rapidement les mises à jour, vous réduisez les risques et évitez les compromissions.

Pour en savoir plus

Ces ressources supplémentaires sur la vulnérabilité à venir pourront vous aider à vous préparer :

Lancez-vous dans les challenges Capture The Flag

Apprenez à résoudre des challenges Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.

Lire la suite

blog feature snyk container custom base recommendations
Blog

Découvrez Evo Agentic AppSec : une sécurité au rythme du développement de l’IA

Le développement piloté par l’IA dépasse les workflows de sécurité traditionnels. L’AppSec agentique de Snyk s’appuie sur des agents de sécurité pour détecter, corriger et vérifier les vulnérabilités en continu, tandis que les équipes définissent les exigences.

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.