New version of cURL to patch critical security flaw (CVE-2023-38545)

cURL 8.4.0, une nouvelle version de la célèbre bibliothèque et outil de ligne de commande pour le transfert de données, a été publiée mercredi 11 octobre. Elle corrige deux vulnérabilités (l'une de haute gravité et l'autre de faible gravité) qui affectaient plusieurs versions antérieures de cURL. L'une d'entre elles (la CVE-2023-38545 de haute sévérité) affecte à la fois l'outil cURL et libcurl, tandis que la seconde (la CVE-2023-38546 de faible sévérité) n'affecte que libcurl.

Une nouvelle version de l'outil cURL a été publiée dans le but de corriger une faille de sécurité potentiellement dangereuse. La bonne nouvelle c'est que le patch cURL 8.4.0 est là et que cette vulnérabilité n'est pas aussi grave que nous pouvions le craindre !

‍

Qu'est-ce que cURL ?

cURL est l'abréviation de "client URL" : un outil en ligne de commande pour transférer des données avec des URL. Très utile pour les développeurs web, elle permet de transférer des données à travers différents protocoles de communication. La commande cURL peut être utilisée entre autres pour transférer des fichiers, envoyer des requêtes FTP, SMTP, HTTP, FTP...

Elle est composée de :

"cURL" : Un outil en ligne de commande incontournable pour les administrateurs système. Il permet de récupérer facilement le contenu des pages web et des API.

"libcurl" : Une bibliothèque de transfert de données largement utilisée dans des équipements grand public (routeurs, imprimantes), des applications web populaires (Netflix, Facebook) et des objets connectés (BMW, Bosch...)

La vulnérabilité CVE-2023-38545 est un "dépassement de tas" (heap overflow) dans le module SOCKS5 de cURL qui peut corrompre la mémoire lors de l'exécution du programme. Malgré sa complexité, Daniel Stenberg, le mainteneur principal de cURL, la considère comme l'une des pires vulnérabilités de sécurité jamais rencontrée. ‍

‍

Plusieurs pré-requis pour exploiter la vulnérabilité

‍Cependant, la bonne nouvelle, et c'est rassurant, c'est qu'il y a plusieurs conditions requises pour que la vulnérabilité puisse être exploitée :

• L'attaquant doit être en mesure de diriger cURL vers un serveur malveillant qu'il contrôle
  ‍
• Il faut que cURL soit configuré avec le proxy SOCKS5 en mode proxy-resolver
  ‍
• cURL doit être configuré pour suivre automatiquement les redirections

Un "heap overflow" n'est possible que dans les applications qui ne définissent pas CURLOPT_BUFFERSIZE lors de l'utilisation de libcurl, ou qui le définissent à une valeur inférieure à 65541. Comme cURL fixe CURLOPT_BUFFERSIZE à 100kB par défaut, il n'est pas vulnérable dans son état par défaut.

La plupart des utilisateurs n'ont généralement pas recours à un proxy SOCKS5 pour leurs connexions, sauf dans des cas d'utilisation spécifiques. Selon les tests réalisés par les chercheurs, la vulnérabilité en question semble susceptible de provoquer un dysfonctionnement de l'application, créant ainsi un déni de service, mais elle ne semble pas permettre l'exécution de code arbitraire.

Cependant, il est important de noter que cela ne garantit pas qu'une nouvelle exploitation de la vulnérabilité ne pourrait pas contredire ces conclusions.

‍

Que faire si vous détectez des versions vulnérables de cURL ?

‍Si vous détectez des versions vulnérables de cURL dans votre projet, nous vous recommandons de faire la mise à jour vers la version sécurisée 8.4.0. Le projet cURL a également proposé des recommandations pour résoudre le problème en toute sécurité.

Un bulletin de sécurité dédié pour la vulnérabilité CVE-2023-38545 est également disponible.‍

‍

Conclusion

‍La vulnérabilité de haute sévérité récemment annoncée dans cURL est préoccupante, car elle pourrait entraîner l'exécution de code à distance, mais n'est pas actuellement considérée comme critique, car elle nécessite qu'un attaquant soit en mesure de contrôler le site web visité ou le nom de domaine transmis à cURL.

L'exploitation de la vulnérabilité est également compliquée par la version de la bibliothèque affectée, ce qui rend difficile la détection au moment de l'exécution. Nous recommandons plutôt de rechercher le comportement post-exploitation, qui est plus facile à détecter et moins susceptible de changer.