A public open sourced tool. Log4J scanner that detects vulnerable Log4J versions (CVE-2021-44228, CVE-2021-45046, etc) on your file-system within any application. It is able to even find Log4J instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and everywhere else Java runs, too! TAG_OS_TOOL, OWNER_KELLY, DC_PUBLIC
Other
638
stars
98
forks
source link
Some archives are not detected when using Java 8 #69
Hi everyone,
First of all thank you for the great project.
This is actually not an issue of log4j-detector but rather a Java bug - however I would like to share my experience.
While using log4j-detector on different systems I encountered some .jar files that were not detected properly. I found that these systems have Java 8 installed (I think Oracle JDK, but AFAIK it uses OpenJDK's codebase), which suffers from the Java-bug https://bugs.openjdk.java.net/browse/JDK-8056934 (apparently the fix got never backported to Java 8). This means that Java 8's java.util.zip.ZipInputStream cannot extract certain zip archives, and hence log4j-detector, which uses java.util.zip.ZipInputStream, cannot analyze them. To be more specific ZipInputStream extracts the first element from these archives and signals end-of-archive, therefore ZipInputStream silently fails to unpack the archive and log4j-detector silently fails to analyze them.
I found that behavior while mitigating the Log4J-vulnerabilities on a system. The system's vendor offered a python-script that re-packs vulnerable Log4J .jars while leaving JndiLookup.class out. After running that script log4j-detector did not mention any files as _POTENTIALLY_SAFE_ (or did you already remove JndiLookup.class?). By analyzing the generated .jars I found they contain data descriptors without the PK\x07\x08 signature, therefore matching the description of the Java bug. The bug description even mentions that older versions of Python's zip implementation generate these archives.
When backporting the fix to OpenJDK 8, everything works as expected - but on production systems that's cumbersome. I am not sure what a good workaround could look like, and how many people still use Java 8 (the issue does not arise when running jdk 8-compiled bytecode on a newer jre). I might give Apache Commons Compress™ a try, though I dislike pulling in external dependencies.
This is of course only related to OpenJDK-based Java implementations (which I believe are most).
Hi everyone, First of all thank you for the great project. This is actually not an issue of log4j-detector but rather a Java bug - however I would like to share my experience.
While using log4j-detector on different systems I encountered some .jar files that were not detected properly. I found that these systems have Java 8 installed (I think Oracle JDK, but AFAIK it uses OpenJDK's codebase), which suffers from the Java-bug https://bugs.openjdk.java.net/browse/JDK-8056934 (apparently the fix got never backported to Java 8). This means that Java 8's
java.util.zip.ZipInputStreamcannot extract certain zip archives, and hence log4j-detector, which usesjava.util.zip.ZipInputStream, cannot analyze them. To be more specific ZipInputStream extracts the first element from these archives and signals end-of-archive, therefore ZipInputStream silently fails to unpack the archive and log4j-detector silently fails to analyze them.I found that behavior while mitigating the Log4J-vulnerabilities on a system. The system's vendor offered a python-script that re-packs vulnerable Log4J .jars while leaving
JndiLookup.classout. After running that script log4j-detector did not mention any files as_POTENTIALLY_SAFE_ (or did you already remove JndiLookup.class?). By analyzing the generated .jars I found they contain data descriptors without thePK\x07\x08signature, therefore matching the description of the Java bug. The bug description even mentions that older versions of Python's zip implementation generate these archives.When backporting the fix to OpenJDK 8, everything works as expected - but on production systems that's cumbersome. I am not sure what a good workaround could look like, and how many people still use Java 8 (the issue does not arise when running jdk 8-compiled bytecode on a newer jre). I might give Apache Commons Compress™ a try, though I dislike pulling in external dependencies.
This is of course only related to OpenJDK-based Java implementations (which I believe are most).