Vulnérabilité Log4Shell de Log4j : un an plus tard, elle est toujours présente

Apache a dû se démener début décembre 2021 pour être prêt à publier des correctifs pour Log4Shell lorsqu’il a rendu public la situation le 9 décembre de l’année dernière. En conséquence, les chercheurs ont rapidement trouvé des cas extrêmes et des solutions de contournement aux correctifs, et Apache a été contraint de publier plusieurs itérations, ce qui a ajouté à la confusion.

« Cette chose était partout, vraiment partout », explique Jonathan Leitschuh, chercheur en sécurité open source. « Les attaquants sautaient dessus, la communauté de la sécurité sautait dessus, des charges utiles volaient partout. »

Les chercheurs disent, cependant, que la réponse globale d’Apache a été solide. Nalley ajoute qu’Apache a apporté des modifications et des améliorations en réaction à la saga Log4Shell et a embauché du personnel dédié pour étendre le support de sécurité qu’il peut offrir aux projets open source afin de détecter les bogues avant qu’ils ne soient livrés dans le code et de répondre aux incidents si nécessaire.

« En peu de temps, deux semaines, nous avons eu des solutions, ce qui est formidable », déclare Nalley. « D’une certaine manière, ce n’est pas une situation nouvelle pour nous, et j’aimerais dire que nous l’avons parfaitement gérée. Mais la réalité est que, même à l’Apache Software Foundation, cela a mis en évidence la responsabilité que nous avons envers tous ceux qui consomment nos logiciels.

À l’avenir, l’aspect le plus préoccupant de la situation est que, même un an plus tard, environ un quart ou plus des téléchargements de Log4j depuis le référentiel Apache Maven Central et d’autres serveurs de référentiel sont toujours remplis de versions vulnérables de Log4j. En d’autres termes, les développeurs de logiciels continuent de maintenir activement les systèmes exécutant des versions vulnérables de l’utilitaire ou même de créer de nouveaux logiciels vulnérables.

« La réalité est que la plupart du temps, lorsque les gens choisissent un composant logiciel open source vulnérable, il existe déjà un correctif », déclare Brian Fox, cofondateur et directeur de la technologie de la société de chaîne d’approvisionnement en logiciels Sonatype, qui exploite Maven. Central et est également un fournisseur de référentiel Apache tiers. « Je suis là depuis longtemps, et je suis blasé, mais c’est vraiment choquant. Et la seule explication est que les gens ne comprennent vraiment pas ce qu’il y a à l’intérieur de leur logiciel .”

Fox dit qu’après la bousculade initiale pour aborder Log4Shell, les téléchargements de versions dans Maven Central et d’autres référentiels ont atteint une étagère où environ 60 % des téléchargements étaient des versions corrigées et 40 % étaient encore des versions vulnérables. Au cours des trois derniers mois environ, Fox et Apache’s Nalley disent avoir vu les chiffres tomber pour la première fois à environ 75/25 %. Comme le dit Fox, cependant, « Après un an, un quart des téléchargements est encore assez terrible. »

« Certaines personnes pensent que Log4j a été un grand réveil pour l’industrie, une panique et un réveil collectifs », dit-il. « Et cela nous a vraiment aidés à élargir le message sur la sécurité de la chaîne d’approvisionnement logicielle, car il n’y avait plus de personnes dans le déni. La chose dont nous parlions tous était réelle maintenant, nous la vivions tous. Mais la seule pression des pairs de Log4j aurait dû forcer tout le monde à mettre à niveau, donc si nous ne pouvons pas amener celui-ci à 100 %, qu’en est-il de tous les autres ? »

Pour les chercheurs en sécurité, la question de savoir comment traiter la longue traîne d’une vulnérabilité est toujours présente. Et le problème ne s’applique pas seulement aux logiciels open source, mais également aux systèmes propriétaires. Pensez simplement au nombre d’années qu’il a fallu pour déplacer les derniers 10 % d’utilisateurs de Windows hors de XP.

« Avec ces pires scénarios – des événements de cygne noir en open source – vous savez juste qu’ils vont continuer à se produire, car la communauté a beaucoup mieux réagi, mais le rythme du développement open source est encore plus rapide », dit Lorenc de ChainGuard. «Nous devons donc trouver l’équilibre entre prévention et atténuation, et continuer à déployer des efforts pour réduire la fréquence autant que possible. C’est comme Les Simpsons meme quand Bart dit: ‘C’est le pire jour de ma vie.’ Et Homer dit non, ‘Le pire jour de ta vie jusqu’à présent.' »