Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL
Qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »
Le 2022-01-25 09:00:35, par Stéphane le calme, Chroniqueur Actualités
Daniel Stenberg, le créateur de cURL, a reçu un courriel en provenance d'une entreprise appartenant au Fortune 500, le classement des 500 premières entreprises américaines classées selon l'importance de leur chiffre d'affaires. Ladite entreprise (ou ses clients) utilisait probablement cURL et, dans le contexte de la vulnérabilité dans la bibliothèque de journalisation Apache log4j, lui a posé une série de questions pour savoir entre autres si cURL s'appuyait sur log4j. « Si vous êtes une entreprise de plusieurs milliards de dollars et que vous êtes préoccupé par log4j, pourquoi ne pas simplement envoyer un e-mail aux auteurs OSS à qui vous n'avez jamais rien payé et exiger une réponse gratuite dans les 24 heures avec beaucoup d'informations ? » a-t-il demandé en présentant le courriel qu'il a reçu
Le 9 décembre, une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE.
Log4j inclut un mécanisme de recherche qui pourrait être utilisé pour effectuer des requêtes via une syntaxe spéciale dans une chaîne de format. Par exemple, il peut être utilisé pour demander divers paramètres comme la version de l'environnement Java via ${java:version}, etc. Ensuite, en spécifiant la clé jndi dans la chaîne, le mécanisme de recherche utilise l'API JNDI. Par défaut, toutes les requêtes sont effectuées en utilisant le préfixe java:comp/env/*; cependant, les auteurs ont implémenté l'option d'utiliser un préfixe personnalisé au moyen d'un symbole deux-points dans la clé. C'est là que réside la vulnérabilité : si jndi:ldap://est utilisé comme clé, la requête va au serveur LDAP spécifié. D'autres protocoles de communication, tels que LDAPS, DNS et RMI, peuvent également être utilisés.
Ainsi, un serveur distant contrôlé par un attaquant pourrait renvoyer un objet à un serveur vulnérable, entraînant potentiellement l'exécution de code arbitraire dans le système ou la fuite de données confidentielles. Tout ce qu'un attaquant doit faire est d'envoyer une chaîne spéciale via le mécanisme qui écrit cette chaîne dans un fichier journal et est donc gérée par la bibliothèque Log4j. Cela peut être fait avec de simples requêtes HTTP, par exemple, celles envoyées via des formulaires Web, des champs de données, etc., ou avec tout autre type d'interactions utilisant la journalisation côté serveur.
La vulnérabilité a été caractérisé par Tenable comme « la vulnérabilité la plus importante et la plus critique de la dernière décennie ».
La sévérité de la brèche est maximale 10 sur l’échelle CVSS.
Des correctifs ont été proposés mais, tour à tour, il a été découvert des faiblesses dans leurs réponses. Au total, les chercheurs ont découvert quatre vulnérabilités en prenant en considération les surfaces d'attaques laissées par trois correctifs proposés pour combler la même faille.
Le créateur de cURL interrogé
cURL (abréviation de client URL request library : « bibliothèque de requêtes aux URL pour les clients » ou see URL : littéralement « voir URL ») est une interface en ligne de commande, destinée à récupérer le contenu d'une ressource accessible par un réseau informatique. La ressource est désignée à l'aide d'une URL et doit être d'un type supporté par le logiciel. Le logiciel permet de créer ou modifier une ressource (contrairement à wget), il peut ainsi être utilisé en tant que client REST.
Le programme cURL implémente l'interface utilisateur et repose sur la bibliothèque logicielle libcurl, développée en langage C. Celle-ci est ainsi accessible aux développeurs qui veulent disposer des fonctionnalités d'accès au réseau dans leurs programmes. Des interfaces ont été créées dans de nombreux langages (C++, Java, .NET, Perl, PHP, Ruby...).
La bibliothèque supporte notamment les protocoles DICT, file, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, Telnet et TFTP.
Son créateur, Daniel Stenberg, a été contacté dans le contexte de la faille log4j par une entreprise disposant d'une capitalisation boursière lui permettant de figurer dans le Fortune 500. Dans un billet de blog, il a indiqué :
« Le vendredi 21 janvier 2022, j'ai reçu cet e-mail. J'ai tweeté à ce sujet et ça a décollé.
« L'e-mail provient d'une entreprise multimilliardaire figurant dans le Fortune 500 qui pourrait apparemment utiliser un produit contenant mon code, ou peut-être qu'ils ont des clients qui le font. Qui sait?
« Je suppose qu'ils le font pour des raisons de conformité et qu'ils ont "oublié" que leurs composants open source ne sont pas automatiquement fournis par des "partenaires" auxquels ils peuvent simplement demander ces informations.
« J'ai répondu très brièvement à l'e-mail et j'ai dit que je serais heureux de répondre avec des détails dès que nous aurons signé un contrat de support.
« Je pense que cela est peut-être un bon exemple de la pyramide open source et que les utilisateurs des couches supérieures ne pensent pas du tout à la façon dont les couches inférieures sont maintenues. Construire une maison sans se soucier du sol sur lequel se trouve la maison ».
Dans son tweet et dans son billet de blog, il supprime le nom de l'entreprise et en donne les raisons : « J'ai très probablement le droit de vous dire qui ils sont, mais je préfère quand même ne pas le faire. (Surtout si je parviens à décrocher un contrat commercial rentable avec eux.) Je pense que nous pouvons trouver ce niveau de droit dans de nombreuses entreprises ».
Et de continuer en ces termes :
« Le niveau d'ignorance et d'incompétence montré dans ce seul e-mail est ahurissant.
« Bien qu'ils ne disent même pas spécifiquement quel produit ils utilisent, aucun code avec lequel j'ai jamais été impliqué ou dont j'ai les droits d'auteur n'utilise log4j et n'importe quel débutant ou meilleur ingénieur pourrait facilement le vérifier.
« Dans la version image de l'e-mail, j'ai complété les champs de nom pour mieux anonymiser l'expéditeur, et dans le texte ci-dessous, je les ai remplacés par NNNN. (Et oui, il est très curieux qu'ils envoient des requêtes sur log4j maintenant, apparemment très tard.) »
Les courriels
Envoyé par L'entreprise
Le 24 janvier, le père de cURL a reçu cette réponse, de la même adresse et elle cite sa réponse :
Envoyé par Entreprise
Le père de cURL a de nouveau répondu (22h29 CET le 24 janvier) à ce courriel qui l'identifiait comme étant "David". Etant donné qu'il y a une histoire à propos d'un David qui a affronté le géant Goliath, il n'a pas pu s'empêcher d'en faire une blague :
Envoyé par Daniel Stenberg
Source : Daniel Stenberg (billet de blog, Tweet)
Et vous ?
Que pensez-vous de la démarche de l'entreprise du Fortune 500 ?
Que pensez-vous de la réponse de David Stenberg ?
Voir aussi :
GitHub restaure le compte du dev qui a intentionnellement corrompu ses bibliothèques, certains développeurs estiment que la suspension était déraisonnable puisqu'il s'agissait de son propre code
Log4j : la directrice du CISA s'attend à des retombées de la faille qui vont s'étendre sur des années et servir à des intrusions futures dans les systèmes des entreprises
Le 9 décembre, une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE.
Log4j inclut un mécanisme de recherche qui pourrait être utilisé pour effectuer des requêtes via une syntaxe spéciale dans une chaîne de format. Par exemple, il peut être utilisé pour demander divers paramètres comme la version de l'environnement Java via ${java:version}, etc. Ensuite, en spécifiant la clé jndi dans la chaîne, le mécanisme de recherche utilise l'API JNDI. Par défaut, toutes les requêtes sont effectuées en utilisant le préfixe java:comp/env/*; cependant, les auteurs ont implémenté l'option d'utiliser un préfixe personnalisé au moyen d'un symbole deux-points dans la clé. C'est là que réside la vulnérabilité : si jndi:ldap://est utilisé comme clé, la requête va au serveur LDAP spécifié. D'autres protocoles de communication, tels que LDAPS, DNS et RMI, peuvent également être utilisés.
Ainsi, un serveur distant contrôlé par un attaquant pourrait renvoyer un objet à un serveur vulnérable, entraînant potentiellement l'exécution de code arbitraire dans le système ou la fuite de données confidentielles. Tout ce qu'un attaquant doit faire est d'envoyer une chaîne spéciale via le mécanisme qui écrit cette chaîne dans un fichier journal et est donc gérée par la bibliothèque Log4j. Cela peut être fait avec de simples requêtes HTTP, par exemple, celles envoyées via des formulaires Web, des champs de données, etc., ou avec tout autre type d'interactions utilisant la journalisation côté serveur.
La vulnérabilité a été caractérisé par Tenable comme « la vulnérabilité la plus importante et la plus critique de la dernière décennie ».
La sévérité de la brèche est maximale 10 sur l’échelle CVSS.
Des correctifs ont été proposés mais, tour à tour, il a été découvert des faiblesses dans leurs réponses. Au total, les chercheurs ont découvert quatre vulnérabilités en prenant en considération les surfaces d'attaques laissées par trois correctifs proposés pour combler la même faille.
Le créateur de cURL interrogé
cURL (abréviation de client URL request library : « bibliothèque de requêtes aux URL pour les clients » ou see URL : littéralement « voir URL ») est une interface en ligne de commande, destinée à récupérer le contenu d'une ressource accessible par un réseau informatique. La ressource est désignée à l'aide d'une URL et doit être d'un type supporté par le logiciel. Le logiciel permet de créer ou modifier une ressource (contrairement à wget), il peut ainsi être utilisé en tant que client REST.
Le programme cURL implémente l'interface utilisateur et repose sur la bibliothèque logicielle libcurl, développée en langage C. Celle-ci est ainsi accessible aux développeurs qui veulent disposer des fonctionnalités d'accès au réseau dans leurs programmes. Des interfaces ont été créées dans de nombreux langages (C++, Java, .NET, Perl, PHP, Ruby...).
La bibliothèque supporte notamment les protocoles DICT, file, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, Telnet et TFTP.
Son créateur, Daniel Stenberg, a été contacté dans le contexte de la faille log4j par une entreprise disposant d'une capitalisation boursière lui permettant de figurer dans le Fortune 500. Dans un billet de blog, il a indiqué :
« Le vendredi 21 janvier 2022, j'ai reçu cet e-mail. J'ai tweeté à ce sujet et ça a décollé.
« L'e-mail provient d'une entreprise multimilliardaire figurant dans le Fortune 500 qui pourrait apparemment utiliser un produit contenant mon code, ou peut-être qu'ils ont des clients qui le font. Qui sait?
« Je suppose qu'ils le font pour des raisons de conformité et qu'ils ont "oublié" que leurs composants open source ne sont pas automatiquement fournis par des "partenaires" auxquels ils peuvent simplement demander ces informations.
« J'ai répondu très brièvement à l'e-mail et j'ai dit que je serais heureux de répondre avec des détails dès que nous aurons signé un contrat de support.
« Je pense que cela est peut-être un bon exemple de la pyramide open source et que les utilisateurs des couches supérieures ne pensent pas du tout à la façon dont les couches inférieures sont maintenues. Construire une maison sans se soucier du sol sur lequel se trouve la maison ».
Dans son tweet et dans son billet de blog, il supprime le nom de l'entreprise et en donne les raisons : « J'ai très probablement le droit de vous dire qui ils sont, mais je préfère quand même ne pas le faire. (Surtout si je parviens à décrocher un contrat commercial rentable avec eux.) Je pense que nous pouvons trouver ce niveau de droit dans de nombreuses entreprises ».
Et de continuer en ces termes :
« Le niveau d'ignorance et d'incompétence montré dans ce seul e-mail est ahurissant.
« Bien qu'ils ne disent même pas spécifiquement quel produit ils utilisent, aucun code avec lequel j'ai jamais été impliqué ou dont j'ai les droits d'auteur n'utilise log4j et n'importe quel débutant ou meilleur ingénieur pourrait facilement le vérifier.
« Dans la version image de l'e-mail, j'ai complété les champs de nom pour mieux anonymiser l'expéditeur, et dans le texte ci-dessous, je les ai remplacés par NNNN. (Et oui, il est très curieux qu'ils envoient des requêtes sur log4j maintenant, apparemment très tard.) »
Les courriels
Et vous ?
Voir aussi :
-
vanquishMembre chevronnéJe suis dans le gratuit (pas l'open source) et je suis régulièrement confronté au problème.
C'est toujours un peu désagréable mais très compréhensible.
Déjà généralement votre interlocuteur est dans la structure depuis 3 ans, alors que le produit est là depuis 15.
Il sait que c'est là, mais n'a aucune idée du modèle économique, parce que ce n'est pas son boulot et qu'il a 150 autres sous-système qu'il ne fait que superviser.
Et en vrai, c'est rarement une question d'argent.
Quand on lui explique que c'est gratuit, ça lui pose souvent un problème, car gratuit cela veux dire pas de contrat et donc personne sur qui rejeter la responsabilité en cas de problème.
Il en a, rétrospectivement, des sueurs froides.
Certains utilisateurs qui pourraient avoir le produit gratuitement préfère payer pour avoir un lien contractuel.le 25/01/2022 à 10:52 -
tabouretMembre éprouvéQuelqu'un peut m'expliquer le lien entre Curl et Log4j?
Sinon on peut aussi demander à Nespresso s'il sont sensibles à Log4j dans la foulée.le 25/01/2022 à 10:24 -
gabriel21Membre chevronnéLe mail ressemble beaucoup à des mails que je peux voir passé en interne ou du client quand le service SSI panique et comme il savent pas où ils habitent, ni ce que font les administrateurs et les développeurs, ils leurs posent la totalité des questions que le RSSI ou tout autre directeur leur a posé.
L'affaire est cocasse, surtout la réponse... Ah bon, vous ne travaillez pas pour nous...
Il s'agit là plus d'une incompétence personnel que d'une société, même si l'ultra procéduralisation et les équipes aux périmètres restreints et hermétiques peuvent être la cause profonde de ce genre de situation.
J'ai par exemple eu le cas d'une demande pour savoir si on avait bien patché une vulnérabilité noyau Windows sur nos serveurs applicatifs qui tournaient sur RHEL et AIX....
Des perles de ce type, j'en vois malheureusement très souvent.le 25/01/2022 à 11:36 -
dolu02Membre avertiC'est justement ce qui leur est reproché, d'être ignorants. S'ils ont des IT en interne (on peut le supposer pour une telle entreprise), pourquoi ne pas leur demander ce qu'il faut faire?le 25/01/2022 à 10:47
-
valtenaMembre confirméLe mail arrive avec pas mal d'impératif. Quand tu lis la tournure du mail la réponse est due. C'est assez arrogant en dehors d'un lien de subordination. Qu'il soit lissé et automatisé n'enlève rien à la chose.le 26/01/2022 à 15:06
-
marsupialExpert éminentDisons qu'il s'agit d'une entreprise qui fait une crise salutaire de parano dans le contexte cybersécuritaire actuel où la Maison Blanche a donné l'ordre à l'administration de bien vérifier la chaîne d'approvisionnement. A mon avis cette organisation a du faire la même demande à tous ses fournisseurs IT. Pour moi, il s'agit d'une démarche allant dans le bon sens. Le dialogue ne doit pas être rompu entre les deux parties évoquées pour déboucher sur une solution amiable. En tout cas, j'ai souri tant à la nouvelle qu'à certain commentaires.le 25/01/2022 à 12:08
-
Pour ceux qui travaillent ou ont eu l'occasion de travailler dans une multinationale (puisque c'est de ce type d'organisation qu'il s'agit manifestement), vous reconnaîtrez assez facilement le style (bourrin) du courriel, qui n'est pas l’œuvre d'un développeur, mais plutôt d'un cadre. Typiquement un chef de projet mis au pied du mur par sa hiérarchie. Sauf qui peut.le 25/01/2022 à 15:09
-
TotoParisMembre expérimentéCe n'est pas un non évènement comme l'a écrit un mec ici. Le ton arrogant et brutal de cette énorme boite est tout simplement à vomir
Sans omettre qu'il avaient l'air de bien être à l'Ouest en plus.le 25/01/2022 à 21:33 -
chrtopheResponsable SystèmesMalheureusement ça devient la norme.le 26/01/2022 à 6:32
-
AoCannailleExpert confirméLe premier mail ressemble a un mail générique prévu pour une mailing liste trés générique.
ça ne m'étonnerait vraiment pas qu'un gars ait fait un grep de toutes les adresses mails de contact de toutes les licences inclus dans leurs produits pour faire un audit bien bourrin. C'est tout à leur honneur même si plus de tact eu été appréciables pour ce mainteneur open source.
En soit, la réponse "Déso, on a pas de contrat, je vous répond pas" est selon moi la meilleure à avoir, et semble bien être compris dans le 2e mail. Je suis persuadé que la situation va évoluer dans le bon sens si tout le monde reste courtois.
Au final c'est un non-événement...le 25/01/2022 à 11:28