Vulnérabilité Log4j 2.16 de gravité élevée (CVE-2021-45105) découverte

Apache a annoncé cette nuit que la version 2.16 de Log4j était également vulnérable à une attaque par déni de service pouvant entraîner le plantage complet de l’application. Sa gravité est classée comme élevée (7,5). Snyk n’a actuellement connaissance d’aucun PoC abouti ni d’aucun exploit en circulation. La référence CVE-2021-45105 a été attribuée et Apache a publié une nouvelle version corrigée (2.17.1), vers laquelle nous vous recommandons de mettre à niveau.

L’équipe de recherche de Snyk suit de près l’évolution de la situation autour de Log4j et continuera de communiquer les détails des vulnérabilités dès qu’elle en aura connaissance.

Dois-je passer à la nouvelle version ?

Il est toujours important de corriger les vulnérabilités de vos applications, mais comme la bibliothèque Log4j en a connu plusieurs, il faut remettre celle-ci en perspective. Il s’agit d’une vulnérabilité de déni de service, et non d’une exécution de code arbitraire comme les deux précédentes : le risque potentiel est donc moins grave. Le point le plus important est ici la facilité d’exploitation. Les deux vulnérabilités précédentes étaient clairement exploitables, comme l’ont démontré des exemples d’exploits fonctionnels et aboutis. Cette nouvelle vulnérabilité de déni de service pourrait être exploitée, mais au moment de la rédaction, les données disponibles ne permettent pas de savoir si cela serait facile ou fréquent.

En résumé, si vous le pouvez et disposez du temps nécessaire pour corriger cette vulnérabilité, passez à la version 2.17.1. Toutefois, pour atténuer le risque d’exécution de code arbitraire, il est plus important de vérifier que toutes vos versions de Log4j sont au minimum en 2.16.0, avant de les mettre toutes à niveau vers la version 2.17.1. Si certains de vos services n’ont pas encore été mis à niveau, il est judicieux de passer directement à la dernière version 2.17.1 afin de corriger tous les problèmes Log4j divulgués récemment.

Pourquoi y a-t-il soudainement autant de vulnérabilités Log4j ?

Si vous vous demandez pourquoi cette bibliothèque fait l’objet de divulgations et de nouvelles versions aussi rapprochées, il est important de comprendre le contexte global et les raisons pour lesquelles de nouvelles mises à niveau ont été publiées et pourraient l’être encore.

1. Une plus grande mobilisation de la communauté – la divulgation initiale de la vulnérabilité critique d’exécution de code à distance dans Log4j a mobilisé l’ensemble de la communauté autour de ce projet. Ainsi, grâce aux efforts de la communauté Java open source, de nombreux bugs qui auraient pu passer inaperçus sont maintenant mis au jour. Cette mobilisation s’étend également à d’autres projets similaires, avec parfois des résultats mitigés, car la volonté de divulguer rapidement des vulnérabilités potentielles prend parfois le pas sur le consensus de la communauté.

2. Un premier correctif de sécurité précipité – bien que les événements exacts qui ont conduit à la divulgation de CVE-2021-44228 soient encore en cours d’éclaircissement, il semble que la période habituelle de divulgation responsable n’ait pas été strictement respectée : des détails sur cette vulnérabilité ont été rendus publics avant qu’un correctif complet soit prêt. L’équipe Apache a dû publier un correctif aussi rapidement que possible. D’autres vecteurs d’attaque et problèmes ont alors été identifiés, entraînant les versions suivantes. 

3. Compatibilité descendante – Log4j est un composant essentiel de l’écosystème Java. Toute nouvelle version doit rester compatible avec les versions précédentes afin d’éviter des ruptures inutiles qui pourraient empêcher les utilisateurs de passer à une version nouvelle et sécurisée. Malheureusement, cette approche nécessaire et prudente ne permet pas de modifier profondément les fonctionnalités de base. D’autres vecteurs d’attaque ou contournements, inconnus au moment de la publication du correctif, peuvent donc exister et être révélés à mesure que la communauté continue d’examiner le paysage des menaces.

Que puis-je faire pour mieux gérer la situation à l’avenir ?

Compte tenu du contexte ci-dessus, il est probable que d’autres vulnérabilités et versions correspondantes soient publiées dans un avenir proche. Les utilisateurs de Log4j (et d’autres packages open source) doivent se préparer à cette éventualité. Voici quelques bonnes pratiques pour renforcer votre programme AppSec et gérer plus facilement ces événements liés aux vulnérabilités zero-day :

• Analysez votre code chaque jour pour détecter les dernières vulnérabilités dans le code géré et même le code non géré.

• Créez une SBOM pour suivre votre chaîne d’approvisionnement logicielle.

• Mettez en place des pipelines DevOps CI/CD automatisés intégrant la sécurité des applications.

• Dans la mesure du possible, adoptez de bonnes pratiques en matière d’open source en mettant à jour vos packages vers des versions plus récentes. Vous pourrez ainsi installer plus facilement les correctifs de sécurité urgents et limiter les problèmes de compatibilité dans votre projet.

Suivez-nous sur LinkedIn, Twitter ou Facebook pour rester au courant des dernières actualités sur Log4Shell et les autres vulnérabilités critiques.