Une faille curl dans les envois HTTP/2 permet à un serveur malveillant de corrompre la mémoire du client. Corrigée en 8.23.0.

Le projet curl a corrigé une faille curl liée à la gestion des envois de données en HTTP/2. Le problème permet à un serveur malveillant, qui reçoit un upload, de corrompre la mémoire du client. Le chercheur qui a signalé le bug est allé plus loin. Il a transformé cette corruption en exécution de code sur la machine qui envoie les données.

Le correctif est disponible depuis le 14 octobre, dans curl 8.23.0. Par conséquent, la mise à jour est la mesure prioritaire pour tous les utilisateurs concernés.

Une faille curl dans les envois HTTP/2

curl est un outil en ligne de commande et une bibliothèque, libcurl, qui transfèrent des données via de nombreux protocoles. Il est présent presque partout : serveurs, postes de travail, objets connectés, applications mobiles. Ainsi, un défaut dans son code touche un très grand nombre de systèmes.

Ici, le bug concerne le moment où curl envoie des données vers un serveur en HTTP/2. Dans ce scénario, c’est le client qui publie un fichier ou un corps de requête. Le serveur, lui, n’est pas forcément de confiance.

Autrement dit, le sens habituel de l’attaque est inversé. On pense souvent qu’un serveur compromis est la cible. Ici, le serveur devient l’attaquant, et le client curl devient la victime.

Il suffit donc que le client se connecte à un serveur contrôlé par un adversaire. Il doit aussi lui envoyer des données en HTTP/2. Dans ces conditions, le serveur peut déclencher une corruption de la mémoire côté client.

Du plantage à l’exécution de code

Une corruption de mémoire est une classe de bugs bien connue. Le programme écrit ou lit des données là où il ne devrait pas. Le plus souvent, cela provoque un simple plantage. Cependant, un attaquant habile peut parfois détourner le comportement du programme.

C’est précisément ce qu’a démontré le chercheur à l’origine du signalement. Sa preuve de concept va au-delà du crash. Elle aboutit à de l’exécution de code sur la machine qui effectue l’upload. En outre, cette démonstration confirme que le défaut n’est pas seulement théorique.

Les informations disponibles ne mentionnent pas d’identifiant CVE. Elles ne donnent pas non plus de score de gravité. Il faut donc se référer à l’avis de sécurité du projet curl pour les détails officiels.

Pourquoi le risque reste limité en pratique

Prendre le contrôle d’un client demande beaucoup de préparation. L’attaquant doit connaître précisément la build de curl utilisée. Il doit aussi maîtriser la disposition de la mémoire du processus visé. Or ces paramètres varient fortement d’un système à l’autre.

Les options de compilation, la version de la bibliothèque et le système d’exploitation changent les conditions. De plus, les protections modernes compliquent l’exploitation. Une attaque réelle contre une cible quelconque est donc difficile à réussir.

Le projet curl en tire une conclusion claire. Il s’attend à ce qu’une attaque réelle se termine, dans la plupart des cas, par un plantage du client. L’exécution de code reste possible, mais elle exige des conditions très précises.

Toutefois, ce constat ne doit pas encourager à repousser la mise à jour. Une attaque ciblée contre un environnement connu reste envisageable. Par exemple, un attaquant peut viser une infrastructure dont il connaît déjà la configuration. Dans ce cas, la précision requise est plus facile à obtenir.

Qui doit être attentif ?

Les environnements suivants méritent une vérification rapide :

• les scripts et tâches automatisées qui envoient des fichiers avec curl ;
• les applications qui embarquent libcurl pour téléverser des données ;
• les conteneurs et images système qui incluent leur propre copie de curl ;
• les outils qui se connectent à des serveurs tiers non maîtrisés.

Comment se protéger de la faille curl

D’abord, identifiez les versions de curl et de libcurl déployées. Utilisez la commande curl --version sur les machines concernées. Ensuite, passez à curl 8.23.0 ou à une version ultérieure.

Beaucoup d’applications intègrent libcurl de façon statique. Par conséquent, la mise à jour du paquet système ne suffit pas toujours. Il faut aussi vérifier les logiciels qui embarquent leur propre version. Les images de conteneurs doivent, elles aussi, être reconstruites.

Par ailleurs, certaines distributions appliquent des correctifs sans changer le numéro de version. Consultez donc les avis de votre distribution avant de conclure qu’un système est vulnérable. Cette étape évite les fausses alertes comme les faux sentiments de sécurité.

Enfin, limitez les risques en attendant le déploiement du correctif. Évitez d’envoyer des données en HTTP/2 vers des serveurs non fiables. Surveillez également les plantages inhabituels de curl. En effet, un crash répété lors d’un upload peut signaler une tentative d’exploitation.

Ce qu’il faut retenir

• Une faille dans la gestion des uploads HTTP/2 de curl permet à un serveur malveillant de corrompre la mémoire du client.
• Un chercheur a démontré une exécution de code sur la machine qui envoie les données.
• Le correctif est inclus dans curl 8.23.0, publié le 14 octobre.
• L’exploitation exige une connaissance précise de la build et de la mémoire. Le projet s’attend plutôt à un plantage.
• Mettez à jour curl et libcurl, y compris dans les applications et conteneurs qui les embarquent.

Source : curl Patches HTTP/2 Upload Flaw After PoC Demonstrates Client-Side Code Execution