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é.
.avif)
.avif)
Les versions affectées de la bibliothèque curl sont susceptibles de présenter une vulnérabilité de type débordement de mémoire tampon basée sur un tas, liée à un problème hérité du protocole proxy SOCKS5. Apprenez à trouver et à corriger ce type de vulnérabilité à l'aide d'une mission jouable.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationLaura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
.avif)
.avif)
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é.
.avif)
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é.

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationLaura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
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é.
Table des matières

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
AI Coding Assistants : Un guide de navigation sécurisée pour la prochaine génération de développeurs
Les grands modèles linguistiques offrent des avantages irrésistibles en termes de rapidité et de productivité, mais ils présentent également des risques indéniables pour l'entreprise. Les garde-fous traditionnels ne suffisent pas à contrôler le déluge. Les développeurs ont besoin de compétences précises et vérifiées en matière de sécurité pour identifier et prévenir les failles de sécurité dès le début du cycle de développement du logiciel.
Sécurité dès la conception : Définir les meilleures pratiques, permettre aux développeurs et évaluer les résultats de la sécurité préventive
Dans ce document de recherche, les cofondateurs de Secure Code Warrior , Pieter Danhieux et Matias Madou, Ph.D., ainsi que des contributeurs experts, Chris Inglis, ancien directeur national américain de la cybernétique (aujourd'hui conseiller stratégique du Paladin Capital Group), et Devin Lynch, directeur principal du Paladin Global Institute, révèleront les principales conclusions de plus de vingt entretiens approfondis avec des responsables de la sécurité des entreprises, y compris des RSSI, un vice-président de la sécurité des applications et des professionnels de la sécurité des logiciels.
Ressources pour vous aider à démarrer
Définir la norme : SCW publie des règles de sécurité gratuites pour le codage de l'IA sur GitHub
Le développement assisté par IA n'est plus un horizon : il est bel et bien là, et il transforme rapidement la manière dont les logiciels sont écrits. Des outils comme GitHub Copilot, Cline, Roo, Cursor, Aider et Windsurf transforment les développeurs en copilotes, permettant des itérations plus rapides et accélérant tout, du prototypage aux projets de refactorisation majeurs.
Bouclez la boucle des vulnérabilités avec Secure Code Warrior + HackerOne
Secure Code Warrior est heureux d'annoncer sa nouvelle intégration avec HackerOne, un leader dans les solutions de sécurité offensive. Ensemble, nous construisons un écosystème puissant et intégré. HackerOne met le doigt sur les vulnérabilités dans les environnements réels, en exposant le "quoi" et le "où" des problèmes de sécurité.
Révélation : Comment l'industrie du cyberespace définit la notion de "Secure by Design" (sécurité dès la conception)
Dans notre dernier livre blanc, nos cofondateurs, Pieter Danhieux et Matias Madou, Ph.D., ont rencontré plus de vingt responsables de la sécurité d'entreprise, notamment des RSSI, des responsables AppSec et des professionnels de la sécurité, afin d'identifier les principales pièces de ce puzzle et de découvrir la réalité qui se cache derrière le mouvement Secure by Design. Il s'agit d'une ambition partagée par les équipes de sécurité, mais il n'y a pas de manuel de jeu commun.