log4j vulnerability / CVE-2021-44228
levesduzw opened this issue · 5 comments
Hi, not an expert in Java, so I'm wondering - does the inclusion of a single log4j class' bytecode expose this project to this newly discovered critical vulnerability?
To me, it doesn't seem like it does, feel free to close the issue in that case.
If it does, could you advise on how to mitigate it? Thanks in advance.
$ jar tf prometheus-proxy.jar | grep log4j
ch/qos/logback/classic/log4j/
ch/qos/logback/classic/log4j/XMLLayout.class
$ jar tf prometheus-agent.jar | grep log4j
ch/qos/logback/classic/log4j/
ch/qos/logback/classic/log4j/XMLLayout.class
Hello. The proxy does not include the Apache log4j jar.
You can see the jars that are included here: https://github.com/pambrose/prometheus-proxy/blob/master/build.gradle
http://slf4j.org/log4shell.html
As an artifact can be pulled into a project transitively, looking at explicit dependency declarations may not be sufficient. We suggest that you look into your project's full dependency tree. For Maven users, this full tree can be obtained with the "mvn dependency:tree" command.If log4j-core, located in the org.apache.logging.log4j group, is absent, then you are fine. Otherwise, either remove the said artifact or upgrade to a log4j 2.x version which fixes the issue.
http://logback.qos.ch/
Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities.
oshai/kotlin-logging#206
fixed in #207 - and anyway since this is just used in tests, there isn't a real risk for users.
So at least "ch.qos.logback:logback-classic" and "io.github.microutils:kotlin-logging" shouldn't have the vulnerability.
Yes, I checked the dependencies as well and no one else is pulling it in either.
./gradlew dependencies | grep log4j comes up empty.
Thank you.