Plus de 35 000 des dépendances Java, soit plus de 8 % du dépôt central Maven (le plus important dépôt de paquets Java), ont été touchés par les vulnérabilités log4j récemment divulguées (1,2), ce qui a eu des répercussions importantes sur l’industrie logicielle. Ces vulnérabilités permettent à un attaquant d’exécuter du code à distance en exploitant la fonction de recherche JNDI non sécurisée exposée par la bibliothèque de logging log4j. Cette fonctionnalité exploitable était activée par défaut dans de nombreuses versions de la bibliothèque.
Cette vulnérabilité a captivé l’écosystème de la sécurité de l’information depuis sa divulgation le 9 décembre, en raison de sa gravité et de son impact étendu. En tant qu’outil de logging populaire, log4j est utilisé par des dizaines de milliers de progiciels (connus sous le nom d’artefacts dans l’écosystème Java) et de projets dans l’industrie du logiciel (Amazon, Docker, Splunk, Atlanssian, Cisco, cPanel, IBM, McAfee ..). Le manque de visibilité des utilisateurs sur leurs dépendances et les dépendances transitives a rendu les correctifs difficiles ; il a également rendu difficile la détermination du rayon d’action complet de cette vulnérabilité.
Quelle est l’étendue de la vulnérabilité de log4j ?
Au 16 décembre 2021, plus que 35 863 des artefacts Java disponibles dans Maven Central ont été trouvés dépendants du code log4j affecté. Cela signifie que plus de 8% de tous les paquets sur Maven Central ont au moins une version qui est affectée par cette vulnérabilité (ces chiffres n’englobent pas tous les paquets Java, tels que les binaires directement distribués, mais Maven Central est un bon indicateur de l’état de l’écosystème).
Quel est le progrès actuel dans la correction de l’écosystème JVM open source ?
Un artefact est compté comme corrigé si l’artefact avait au moins une version affectée et a publié une version stable supérieure (selon le versionnement sémantique de chaque dépendance) qui n’est pas affectée. Un artefact affecté par log4j est considéré comme corrigé s’il a été mis à jour vers la version 2.16.0 (2.17.0 à date d’aujourd’hui) ou s’il a complètement supprimé sa dépendance à log4j.
A ce moment-là, près de cinq mille artefacts affectés ont été corrigés. Cela représente une réponse rapide et un effort colossal de la part des mainteneurs de log4j et de la communauté élargie des consommateurs de logiciels libres.
Cela laisse plus de 30 000 artefacts affectés, dont beaucoup dépendent d’un autre artefact à corriger (la dépendance transitive) et sont probablement bloqués.
Attention : Les mesures d’atténuation ne sont pas des solutions
La mise à jour de Log4j est la seule façon d’être sûr.
- Si vous utilisez Java 8 (ou d’une version ultérieure) : vous devez passer à la version 2.17.0 de Log4j.
- Si vous utilisez Java 7 : vous devez passer à la version 2.12.2 de Log4j.
Au début de l’apparition des vulnérabilités, la plupart des gens se sont concentrés sur les mesures d’atténuation. La plus courante était probablement d’ajouter ce paramètre JVM :
-Dlog4j2.formatMsgNoLookups=true ou de définir cette variable d’environnement :
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Ces méthodes ont fonctionné pour la vulnérabilité initiale, mais n’arrêtent pas toutes les attaques. Elles sont listées comme « discréditées » sur la page des vulnérabilités de sécurité d’Apache Log4j.
Cela vaut toujours la peine de le faire en attendant les correctifs des fournisseurs, mais cela ne fait que limiter votre exposition. Il ne s’agit pas d’une correction complète. Ne faites pas cela et supposez que la partie est terminée !
Une autre option consistait à supprimer complètement la classe JndiLookup.class. Cette solution est toujours considérée comme une mesure d’atténuation valable si vous n’êtes pas en mesure d’effectuer une mise à niveau. Cela peut sembler effrayant, mais si un correctif du fournisseur n’est pas à venir, vous devez évaluer les risques.
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Outre les mesures d’atténuation directes, vous devez également tenir compte de la situation dans son ensemble. Les applications qui sont accessibles au public (Internet-Facing applications) sont clairement exposées à un risque énorme. Si les applications ne sont ouvertes au public du réseau de votre entreprise, le risque est réduit. Ça ne vaut pas dire qu’il faut ignorer les applications internes, mais il faut peut-être donner la priorité aux systèmes à haut risque.
Résumé rapide
- Pas une application Java (tournant sous JVM) : ne vous inquiétez pas.
- Application Java qui n’utilise pas Log4j : ne pas s’inquiéter.
- Application Java qui utilise Log4j 1.x : ne vous inquiétez pas de ces vulnérabilités. Bien sûr, un code plus ancien peut être sensible à d’autres potentiels vulnérabilités.
- Application Java utilisant Log4j 2.x. Java 8 (ou version ultérieure) : mettre à niveau vers la version 2.17.0* de Log4j.
- Application Java qui utilise Log4j 2.x. Java 7 : effectuer une mise à niveau vers Log4j version 2.12.2*.
- Si la mise à niveau de Log4j n’est pas une option immédiate, ou si vous attendez qu’un fournisseur publie un correctif, envisagez des mesures d’atténuation jusqu’à ce que les mises à niveau soient possibles.
Combien de temps faudra-t-il pour que cette vulnérabilité soit corrigée dans l’ensemble de l’écosystème JAVA ?
C’est difficile à dire. Nous avons examiné tous les avis critiques publiés concernant les paquets Maven pour avoir une idée de la rapidité avec laquelle d’autres vulnérabilités ont été corrigées. Moins de la moitié (48 %) des artefacts affectés par une vulnérabilité ont été corrigés, ce qui laisse présager une longue attente, probablement des années.
Mais les choses semblent prometteuses sur le front de log4j. Après moins d’une semaine, 4 620 artefacts affectés (près de 13%) ont été corrigés. Cette statistique, plus que toute autre, témoigne de l’effort massif des mainteneurs de logiciels libres, des équipes de sécurité informatique et des consommateurs du monde entier.
Next Step ?
Un grand merci aux mainteneurs de logiciels libres et les consommateurs ainsi que nos collaborateurs qui ont déjà mis à jour leurs versions de log4j. Nous encourageons la communauté open source et nos partenaires à continuer à renforcer la sécurité de leurs paquets en activant les mises à jour automatiques des dépendances et en ajoutant des mesures d’atténuation de la sécurité.
Bien que la situation semble sombre pour l’instant, les utilisateurs finaux devraient tout de même s’efforcer d’atténuer cette vulnérabilité en suivant les conseils susmentionnés et les directives fournies par les experts en cybersécurité.
Sources :
Par Hamza Abqar
Tech Lead Java / DevOps chez ITValue Consulting