Plongée profonde : Trouver et corriger des vulnérabilités de haute sévérité dans libcurl/curl

Il y a peu, les communautés de la sécurité et du développement ont été averties par un avis du développeur principal du projet curl, Daniel Stenberg, qui a publié une malheureuse missive indiquant qu'une nouvelle version de curl - distribuée le 11 octobre - avait été publiée pour corriger deux vulnérabilités de sécurité à fort impact, dont l'une qu'il décrit comme "probablement la pire faille de sécurité de curl depuis longtemps".

Un postmortem sur le blog de Stenberg indique que les versions concernées de la bibliothèque curl sont susceptibles de présenter une vulnérabilité de débordement de mémoire tampon basée sur un tas, liée à un problème hérité du protocole proxy SOCKS5 utilisé depuis 2002.

Avec son utilisation en tant qu'outil de ligne de commande remontant à 1998, curl est largement considéré comme un pilier fondamental de l'internet. Avec une histoire aussi riche et une utilisation aussi répandue, il s'agit d'une dépendance qui, si elle s'avère vulnérable, pourrait avoir des conséquences permanentes sur la cybersécurité en général.

Cet incident présente des similitudes avec l'attaque dévastatrice Log4Shell dans Log4j, une autre dépendance vulnérable qui est toujours exploitée près de deux ans plus tard.
‍
>>> Testez vos connaissances dès maintenant avec notre mission curl!‍

La vulnérabilité : Débordement de mémoire tampon

L'exploitation est détaillée sous CVE-2023-38545, et concerne les versions curl 7.69.0 à 8.3.0 incluse. Le bogue principal est une vulnérabilité de débordement de tampon basée sur le tas, les rapports initiaux notant qu'une exploitation réussie pourrait conduire à une attaque d'exécution de code à distance (RCE) plus dévastatrice. Bien qu'il s'agisse d'un flux de travail possible pour un acteur de la menace, il s'agit d'un cas d'utilisation rare plutôt que d'une évidence.

Le seul point positif permettant d'atténuer certains risques est que la communication malveillante doit passer par un proxy SOCKS5, ce qui est un déploiement relativement rare.

Comparable à l'exploit curl, jetons un coup d'œil à cette explication sur le débordement de tampon :

Lorsque l'on demande à curl d'utiliser un proxy SOCKS5, il transmet le nom d'hôte et le proxy le résout. Cependant, si le nom d'hôte dépasse la limite de 255 octets, curl résoudra le nom d'hôte localement (comme le montre l'extrait de code ci-dessous : source).

En cas de lenteur de l'échange entre le client et le mandataire, il est possible que le nom d'hôte long soit copié dans la mémoire tampon au lieu de l'adresse résolue (plus courte). La portion de mémoire allouée ne permet qu'une valeur de 255 octets, donc si elle reçoit une valeur qui dépasse cette limite, les données déborderont des limites de la mémoire tampon.

>>> Essayez-le par vous-même dans cette mission jouable!

Le débordement de mémoire tampon est un vecteur d'attaque puissant, qui peut être présent dans de nombreux langages de programmation anciens. Dans ce cas particulier, l'exploitation a ouvert la voie à une attaque plus sérieuse et plus dommageable sous la forme d'un RCE dans certains contextes, bien que cette voie reste peu courante et peu probable.

Comment pouvez-vous atténuer le risque de dépassement de tampon ?

À ce stade, la priorité absolue est d'appliquer les correctifs à toutes les instances vulnérables, en rappelant que l'utilisation de curl est tellement répandue qu'il n'est pas nécessairement évident ou annoncé que les composants de votre système incluent la dépendance en cours d'utilisation. Dans ce cas, un audit et des correctifs ultérieurs sont nécessaires. 

En général, les failles de débordement de mémoire peuvent être atténuées par l'utilisation d'un langage à mémoire sécurisée comme Rust. Cependant, comme c'est le cas avec un projet tentaculaire comme curl, il n'est pas pratique de le porter à un autre langage ou de le réécrire sur un coup de tête. Comme le note Stenberg en évoquant la possibilité d'utiliser et de prendre en charge davantage de dépendances écrites dans des langages à mémoire sécurisée - ou l'alternative consistant à remplacer progressivement certaines parties de curl - "... le développement se fait... actuellement à une vitesse presque glaciale et montre avec une clarté douloureuse les défis à relever. curl restera écrit en C dans un avenir prévisible". Ce n'est pas une mince affaire, et les implications en matière de sécurité sont immenses.

Des erreurs de sécurité peuvent se produire et se produiront, et il n'est pas toujours possible de compter sur les scanners et les tests pour détecter tous les vecteurs d'attaque possibles. C'est pourquoi notre meilleure arme dans la lutte contre ces bogues est un engagement à une sensibilisation permanente à la sécurité et au renforcement des compétences.
‍

Vous souhaitez en savoir plus sur la manière d'écrire du code sécurisé et de réduire les risques ?

Essayez notre Heap Overflow gratuitement.

Si vous souhaitez obtenir plus de conseils gratuits en matière de codage, consultez les sites suivants Secure Code Coach pour vous aider à rester au fait des meilleures pratiques en matière de codage sécurisé.