Introduction

Signale actuellement les versions log4j-core 2.3.2, 2.12.4 et 2.17.1 comme _SAFE_, 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0 et 2.17.0 comme _OKAY_ et toutes les autres versions comme _VULNERABLE_ (bien qu'il signale les versions antérieures à 2.0-beta9 comme _POTENTIALLY_SAFE_). Il signale les anciennes versions log4j-1.x comme _OLD_.

Peut détecter correctement log4j à l'intérieur de jars/wars exécutables Spring Boot, des dépendances mélangées dans des uber jars, des jars shaded, et même des fichiers jar décompressés simplement posés sur le système de fichiers (alias *.class).

Nous maintenons actuellement une collection d'échantillons log4j que nous utilisons pour les tests.

Exemple d'utilisation :

Comprendre les résultats

_VULNERABLE_ -> Vous devez mettre à niveau ou supprimer ce fichier.

_OKAY_ -> Nous signalons cela pour les versions Log4J 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0 et 2.17.0. Nous recommandons de passer à la version 2.17.1.

_SAFE_ -> Nous ne signalons actuellement cela que pour les versions Log4J 2.3.2, 2.12.4 et 2.17.1 (et ultérieures).

_OLD_ -> Vous êtes à l'abri de CVE-2021-44228, mais vous devriez prévoir de mettre à niveau car Log4J 1.2.x est en fin de vie depuis 7 ans et présente plusieurs vulnérabilités connues.

_POTENTIALLY_SAFE_ -> Le fichier « JndiLookup.class » n'est pas présent, soit parce que votre version de Log4J est très ancienne (antérieure à 2.0-beta9), soit parce que quelqu'un a déjà supprimé ce fichier. Assurez-vous que c'est bien un membre de votre équipe ou entreprise qui a supprimé « JndiLookup.class » si tel est le cas, car des attaquants sont connus pour supprimer eux-mêmes ce fichier afin d'empêcher d'autres attaquants concurrents d'accéder aux systèmes compromises.

Utilisation

Compiler à partir des sources :

Tests :

Nous maintenons une collection d'échantillons log4j ici : https://github.com/mergebase/log4j-samples

Licence

GPL version 3.0

Foire aux questions

Comment ça fonctionne ?

Le compilateur Java stocke les littéraux de chaîne directement dans les fichiers *.class compilés. Si log4j-detector détecte un fichier nommé « JndiManager.class » sur votre système de fichiers, il examine alors ce fichier à la recherche de la chaîne : « Invalid JNDI URI - {} ». Il s'avère que ce littéral de chaîne spécifique n'est présent que dans la version corrigée de Log4J (version 2.15.0). Toutes les versions de Log4J sans cette chaîne sont vulnérables.

Cette même technique d'examen des fichiers *.class pour les littéraux de chaîne est encore étendue pour détecter avec précision les versions sûres 2.3.2, 2.12.4 et 2.17.1.

Ce scanner ne signale que les hits contre la bibliothèque log4j-core. Qu'en est-il de log4j-api?

De nombreux scanners (y compris le propre Dependabot de GitHub) signalent actuellement les bibliothèques « log4j-core » et « log4j-api » comme vulnérables. Ces scanners sont incorrects. Il n'existe actuellement aucune version de la bibliothèque « log4j-api » qui puisse être exploitée par l'une de ces vulnérabilités.

Chez MergeBase, nous sommes fiers de la précision de notre scan. Vous êtes déjà assez occupé à corriger et défendre vos systèmes. Nous ne voulons pas que vous perdiez du temps avec des faux positifs. C'est pourquoi nous ne signalons aucun hit contre log4j-api.

Pourquoi signaler les versions 2.3.1, 2.10.0, 2.12.2, 2.12.3, 2.15.0, 2.16.0 et 2.17.0 ?

La version 2.10.0 est importante car c'est la première version où la fonctionnalité vulnérable de « message lookup » de Log4J peut être désactivée via la configuration Log4J.

La version 2.12.2 est importante car c'est une version compatible Java 7 de Log4J qui n'est pas vulnérable à CVE-2021-44228.

Les versions 2.15.0 et 2.16.0 sont importantes car ce sont les premières versions où la configuration par défaut de Log4J n'est pas vulnérable à CVE-2021-44228.

Et les versions 2.3.2, 2.12.4 et 2.17.1 sont importantes car elles ne sont pas vulnérables aux CVE découvertes plus récemment telles que CVE-2021-45046 et CVE-2021-45105. Bien que ces dernières soient des vulnérabilités beaucoup moins graves, nous prévoyons que tout le monde voudra appliquer un correctif vers l'une des versions 2.3.2, 2.12.4 ou 2.17.1.

Que signifient ces résultats « file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar » ?

Le « ! » signifie que le détecteur log4j est entré dans une archive zip (par ex., *.zip, *.ear, *.war, *.aar, *.jar). Étant donné que les fichiers zip peuvent contenir des fichiers zip, un seul résultat peut contenir plus d'un indicateur « ! » dans son résultat.

Note : le détecteur log4j n'entre de manière récursive que dans les archives zip. Il n'entre pas dans les tar, gz, bz2, etc. La raison principale est que les systèmes Java sont souvent configurés pour exécuter des jars à l'intérieur de jars, mais ils ne sont jamais configurés pour exécuter d'autres formats de fichiers (que je sache !). Ainsi, une copie log4j à l'intérieur d'un *.tar.gz n'est probablement pas accessible pour un système Java en cours d'exécution, et par conséquent, ce n'est pas une vulnérabilité digne d'être signalée.

2ème note : pour les zips imbriqués, notre scanner charge complètement le zip intérieur en mémoire (à l'aide de ByteArrayInputStream) avant de tenter de le scanner. Vous devrez peut-être allouer plus de mémoire à Java si vous avez des zips intérieurs extrêmement volumineux sur votre système (par exemple, 1 Go ou plus).

Qu'en est-il de Log4J 1.2.x ?

Seules les versions de Log4J 2.x (de 2.0-beta9 à 2.14.1) sont vulnérables à CVE-2021-44228.

Comment puis-je être sûr que ce n'est pas un cheval de Troie déguisé en détecteur Log4J ?

Excellente question ! Étant donné que nous incluons le code source complet ici sur Github (les 2500 lignes de Java), ainsi que les étapes pour le compiler, et comme cet outil n'a aucune dépendance, il ne devrait pas vous falloir trop de temps pour étudier attentivement le code à votre satisfaction. Si vous ne faites pas confiance à Maven, vous pouvez aller directement dans le répertoire « src/main/java/com/mergebase/log4j » et taper « javac *.java ». Cela fonctionne aussi !

Nous signons également le jar pré-compilé que nous conservons à la racine du dépôt (./log4j-detector-2021.12.29.jar) avec la clé de signature de code MergeBase. Veuillez exécuter « jarsigner -verbose -verify log4j-detector-2021.12.29.jar » pour le confirmer.

Qu'est-ce que MergeBase en bref ?

MergeBase est une entreprise d'Analyse de Composition Logicielle (SCA) basée à Vancouver, Canada. Nous sommes similaires à des entreprises comme Snyk, Sonatype, Blackduck, etc., en ce sens que nous aidons les entreprises à détecter et gérer les bibliothèques open-source vulnérables dans leurs logiciels. Jetez un coup d'œil ! Nous avons une grande précision, une excellente prise en charge des langages, et nous ne sommes pas trop chers non plus : mergebase.com/pricing.

Nous serions ravis que quelqu'un profite d'un essai gratuit de 2 semaines de notre produit SCA ! Et si vous envoyez un email à notre PDG ([email protected]) avec pour objet « log4j-detector », nous prolongerons votre essai gratuit à 4 semaines.