Nouvelle vulnérabilité critique dans OpenSSL : ce que vous devez savoir
31 octobre 2022
0 minutes de lectureNote 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.

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.

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 testpour afficher les résultats directement dans votre CLI, ousnyk monitorpour 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
--unmanagedlorsque vous exécutezsnyk test.
Pour tester des images de conteneurs, exécutez
snyk container testpour afficher les résultats directement dans votre CLI, ousnyk container monitorpour 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
testci-dessus, ajoutez l’option--print-deps. Si vous utilisez la commandemonitor, 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 versiondans votre terminal :

Comment atténuer la nouvelle vulnérabilité OpenSSL
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.
Évaluez vos applications et votre infrastructure pour déterminer si vous utilisez OpenSSL 3.0 ou une version ultérieure, où que ce soit.
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 :
Docker DSA 2022-0001 : un avis temporaire publié en prévision du CVE public, qui fournit une liste des packages et images de conteneurs concernés.
SANS Internet Storm Center : liste des distributions Linux concernées
DistroWatch : liste des distributions Linux concernées
Avis de Node.js : la mise à jour de sécurité de Node.js, qui souligne que Node.js v18.x et v19.x utilisent OpenSSL v3
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.



