Skip to main content

Découverte d’une vulnérabilité de gravité élevée dans libcurl et curl (CVE-2023-38545)

Écrit par:
Hadas Bloom
Hadas Bloom
Tal Dromi
Micah Silverman
Micah Silverman
feature-curl-vuln

4 octobre 2023

0 minutes de lecture

Mise à jour : 11 octobre 2023

Aujourd’hui à 6 h (UTC), les gestionnaires de cURL ont publié les versions 8.4.0 de curl et libcurl pour corriger un risque de débordement de tampon dans la pile de gravité élevée (preuve de concept et notification initiale) qui pourrait avoir un impact sur les systèmes présentant une configuration et des conditions préalables spécifiques.

Cette vulnérabilité zéro-day est présente dans des paquets provenant de plusieurs écosystèmes open source gérés et non gérés, y compris (mais sans s'y limiter) C/C++, cargo, Cocoapods, npm, NuGet, pip et pub, ainsi que dans diverses distributions Linux, notamment comme Alpine, Debian et RHEL.

Il s’agit de la première vulnérabilité de gravité élevée détectée dans curl depuis plusieurs années (la précédente remonte au début de l’année 2021).

blog-curl-vuln-chart
Capture d’écran du tableau des vulnérabilités de cURL

Les versions de curl/libcurl touchées (depuis mars 2020) sont les suivantes :

  • Versions concernées : libcurl 7.69.0 à 8.3.0 (incluse)

  • Versions non concernées : libcurl < 7.69.0 et >= 8.4.0

L’exploit est d’une complexité jugée élevée, car il n’est possible que dans certains scénarios. Comme expliqué dans l’article du gestionnaire intitulé How I made a heap overflow in curl, la bibliothèque vulnérable doit contacter un serveur non contrôlé/compromis (pour l’exploiter via une redirection HTTP) ou utiliser une URL contrôlée par un attaquant via un proxy SOCKS5 sur lequel la résolution du nom d’hôte est activée. Mais même lorsque ces conditions sont réunies, on ne parle ici que d’un dépassement de tampon avec un jeu de caractères réduit. Sur les systèmes modernes, les débordements de tampon sont très difficiles à transformer en exécution de code arbitraire, ce qui explique la complexité de l’exploit.

Maintenant que la vulnérabilité est divulguée et suivie, vous pouvez utiliser les rapports de Snyk pour identifier les projets concernés en sélectionnant votre organisation, puis en choisissant Reports dans la barre latérale. Sélectionnez +Add Filter sous les détails de problème, puis CVE. Saisissez ensuite le numéro de la CVE : CVE-2023-38545

blog-curl-vuln-filter
Filtrez la vue jusqu’à la CVE-2023-38545

Cet article sera mis à jour si de nouvelles informations sont disponibles.

Mise à jour : 4 octobre 2023

Le 3 octobre 2023, Daniel Stenberg, gestionnaire de longue date de curl et créateur de la bibliothèque, a publié un article sur LinkedIn et X (anciennement Twitter) concernant la disponibilité de la version 8.4.0 de curl. Cette mise à jour corrigera ce qui est « probablement le pire problème de sécurité identifié dans curl depuis longtemps ».Ce problème doit d’autant plus être pris au sérieux que les gestionnaires de curl ont par le passé tenu à limiter l’impact de la plupart des vulnérabilités touchant la bibliothèque. En témoigne cet article récent, en anglais : CVE-2020-19909, où tout le problème des CVE. Si dans ce cas précis, ils évoquent publiquement un risque, c’est sans doute que l’heure est grave.

La version corrigée (4.8.0) sera disponible le 11 octobre 2023 autour de 6 h (UTC).

Il y a quelques heures (le 4 octobre 2023), les CVE qui seront utilisées pour décrire la vulnérabilité ont été annoncées dans une discussion GitHub.

La CVE-2023-38545est considérée comme étant de gravité élevée et touche à la fois libcurl et curl. Un autre problème, de gravité basse et associé à la CVE CVE-2023-38546 (qui ne touche cette fois que libcurl), sera lui aussi corrigé.

Que savons-nous pour l’instant ?

cURL est un projet populaire qui propose à la fois la bibliothèque libcurl pour les transferts d’URL et l’outil en ligne de commande curl pour l’obtention et l’envoi de données à l’aide d’URL. cURL a été créé il y a 27 ans et est utilisé très largement depuis 1996. 

Beaucoup des distributions Linux que Snyk prend en charge, pour ne pas dire toutes, utilisent libcurl. L’impact potentiel de cette vulnérabilité est donc étendu.

Comment préparer la correction

  • Vérifiez les conteneurs et paquets que vous utilisez pour estimer votre exposition.

  • Identifiez les hôtes sur lesquels curl est installé et déterminez comment il a été installé.

  • Vérifiez la version de curl que vous utilisez avec la commande curl --version.

Évaluez votre exposition.

Avant la publication du correctif de libcurl, utilisez Snyk pour identifier rapidement les projets open source et les images de conteneurs pouvant être touchés. 

Accédez à la section Dependencies dans la barre latérale de Snyk. Dans la vue Dependencies, développez le filtre du même nom et saisissez « curl ». Vous pouvez sélectionner des versions spécifiques ou cocher Select all. Cliquez ensuite en dehors du filtre. Tous les projets contenant les versions de libcurl sélectionnées s’affichent. Vous pouvez accéder au détail des projets et des dépendances pour mieux évaluer votre exposition et déterminer les correctifs à apporter en priorité.

Identifiez les hôtes sur lesquels curl est installé

De nombreux systèmes d’exploitation intègrent curl par défaut. Son emplacement dépend du système d’exploitation et de la méthode d’installation. Vous pouvez déterminer rapidement si curl est installé dans votre chemin en exécutant la commande curl --version

En cas d’erreur, elle affichera la première version de curl détectée dans votre chemin. Notez qu’une installation dans plusieurs emplacements est possible. Par exemple, sur les ordinateurs Apple récents, curl est installé par défaut dans /usr/bin/curl, mais peut aussi avoir été installé via homebrew. Vous pouvez déterminer la version de votre chemin en exécutant la commande which curl. Autres emplacements possibles sur macOS et les systèmes d’exploitation basés sur Linux :

  • /bin/curl

  • /usr/bin/curl

  • /usr/local/bin/curl

  • /opt/homebrew/opt/curl

Veillez à repérer toutes les occurrences à mettre à jour.

Comment réagir une fois la nouvelle version disponible

Le jour de la publication du correctif, a priori le 11 octobre 2023 autour de 6 h (UTC), vous devez être prêt à passer à la version 8.4.0. Lorsque la nouvelle version sera disponible, Snyk disposera de davantage d’informations sur la vulnérabilité, informations qui seront publiées dans cet article (avec des liens vers d’éventuels nouveaux articles liés).

Mettez à jour les paquets et conteneurs vulnérables

Utilisez les informations que vous avez réunies en préparation de la mise à jour de vos projets et images de conteneurs pour choisir la version corrigée de libcurl. Les différents écosystèmes et distributions Linux risquent d’attendre cette date pour faire évoluer leur utilisation des paquets touchés. Divers correctifs seront donc probablement publiés progressivement. Par exemple, certains gestionnaires peuvent attendre des correctifs appliqués en amont pour mettre à jour leurs propres images de conteneur ou paquets, tandis que d’autres préféreront déployer le correctif directement. Dans tous les cas, Snyk vous aidera à localiser et corriger les problèmes.

Mettez à jour curl sur vos appareils

Une fois la version corrigée du fichier binaire de curl disponible, mettez à jour celles que vous avez installées. Nous vous dévoilerons des conseils qui vous aideront à réaliser cette opération dans un autre article. Il existe de nombreuses façons d’installer curl et les méthodes de mise à jour peuvent varier selon le système d’exploitation. 

Comment agit Snyk ?

Snyk a publié un avis temporaire concernant cette vulnérabilité de gravité élevée. Son contenu sera mis à jour à mesure que de nouvelles informations seront divulguées. 

Les experts en sécurité de Snyk gardent l’œil sur les mises à jour publiées, les informations sur la vulnérabilité, les échanges sur les médias sociaux et bien d’autres éléments pour communiquer un maximum d’informations à ses clients. De plus, nous menons différentes enquêtes pour déterminer si d’autres paquets en aval peuvent être touchés. Nous mettrons à jour cet article si besoin.