Secu
Deux failles dans OpenSSL qui doivent interpeler RSSI et DSI
Par Laurent Delattre, publié le 08 novembre 2022
Le 25 octobre dernier, le projet OpenSSL a annoncé la disponibilité d’une mise à jour critique de sa bibliothèque pour corriger deux failles de sécurité jugées « hautes ». Une annonce qui n’a rien d’anodine pour les DSI…
OpenSSL est l’une des bibliothèques Open Source les plus communément utilisées pour sécuriser les échanges et transferts en SSL. L’annonce de deux nouvelles vulnérabilités au cœur de cette bibliothèque doit ramener en mémoire les galères rencontrées en début d’année avec la vulnérabilité Log4Shell de la bibliothèque Log4j.
Les vulnérabilités au sein des bibliothèques open-source ultras populaires sont un vrai casse-tête de sécurité. Car elles impactent un grand nombre d’applications aussi bien externes que développées en interne. Sans une vraie politique de gouvernance des codes sources ainsi que des dépendances et des bibliothèques tierces, il est long, complexe et coûteux de faire le ménage et patcher les failles.
Le projet OpenSSL a mis à disposition une nouvelle version de sa librairie pour corriger deux vulnérabilités de sécurité, initialement qualifiées de critiques, sur les versions 3.0 et supérieures. Pour rappel, OpenSSL est destinée à la cryptographie, la librairie est largement utilisée notamment pour le SSL. Résultat, l’an dernier, un rapport Veracode sur l’état de la sécurité des logiciels révélait que 79% des bibliothèques utilisées dans les logiciels d’entreprises n’étaient jamais mises à jour !
À LIRE AUSSI :
Alors, oui, les vulnérabilités dévoilées par OpenSSL ne sont pas aussi critiques qu’on pouvait le craindre. Néanmoins, il est important de les patcher et de soit tester les processus de patching imaginées après l’incident Log4j, soit vraiment commencer à réfléchir à une gouvernance des bibliothèques (open-source ou non) au cœur de la chaîne CI/CD.
Les deux vulnérabilités, de type « buffer overflow » ou débordement de mémoire, baptisées CVE-2022-3786 et CVE-2022-3602, affectent les versions d’OpenSSL disponibles depuis le début de l’année. Les deux failles peuvent amener – en principe – à l’exécution de code à distance. Le dépassement de tampon peut être déclenché lors de la vérification du certificat X.509, spécifiquement pendant l’étape de vérification des contraintes de nom. Elles concernent toutes les applications utilisant OpenSSL 3.0 pour vérifier les certificats X.509 reçus de sources non fiables. Ce qui inclut les clients TLS et les serveurs TLS qui sont configurés pour utiliser l’authentification client TLS.
À LIRE AUSSI :
Après quelques jours de tests, si le groupe chargé de la sécurité chez openSSL préconise toujours une mise à jour vers la version 3.0.7, le niveau des vulnérabilités a été abaissé de critiques à hautes. La raison ? Ces failles ne donnent finalement pas vraiment la possibilité à l’attaquant d’exécuter du code à distance, à minima dans les configurations courantes. Car elle n’affecte essentiellement que les clients (pas les serveurs) et se révèle difficile à exploiter d’autant qu’il faut pour l’attaquant mettre la main sur un certificat signé par une autorité de confiance. Voilà qui devrait limiter l’impact de ces failles qui si elles ne seront probablement jamais exploitées à large échelle (« in the wild ») peuvent quand même servir de porte d’entrée à des attaques ciblées notamment étatiques.
Daniel Sweet, directeur de la Sécurité des Endpoints chez Tanium, alerte les DSI sur le fait que « ces failles OpenSSL doivent quand même faire l’objet d’une grande attention d’autant qu’elles sont difficiles à remédier. En effet, ce type de vulnérabilité peut évoluer et doit être corrigé de toute urgence pour éliminer les failles potentielles qu’il crée, surtout si l’on considère la nature publique de nombreuses implémentations. De nombreux exemples de code Proof-of-Concept sont désormais en ligne et nous pouvons nous attendre à connaître de nouvelles informations au sujet de ces vulnérabilités, même si elles n’atteindront jamais le niveau de criticité indiqué initialement. »
Dit autrement, ce n’est pas parce qu’elles sont moins critiques qu’originellement annoncé que les DSI et RSSI doivent les négliger et plus encore retarder leur mise en œuvre d’une gestion avancée des bibliothèques et de leur patching.
En attendant, les responsables cybersécurité peuvent désactiver l’authentification client TLS, si elle est utilisée sur leurs serveurs SSL, jusqu’à ce que les correctifs soient appliqués.
La nouvelle version d’OpenSSL embarquant les corrections pour ces vulnérabilités porte le numéro « 3.0.7 ».
À LIRE AUSSI :
