On 12/15/21 11:53 AM, Scott Derrick wrote:
I find these files in my solr install
./server/lib/ext/log4j-core-2.11.0.jar
./server/lib/ext/log4j-1.2-api-2.11.0.jar
./server/lib/ext/log4j-api-2.11.0.jar
./server/lib/ext/log4j-slf4j-impl-2.11.0.jar
./contrib/prometheus-exporter/lib/log4j-core-2.11.0.jar
./contrib/prometheus-exporter/lib/log4j-api-2.11.0.jar
./contrib/prometheus-exporter/lib/log4j-slf4j-impl-2.11.0.jar
If I replace them all with version 2.16 will that clear this up? DO I
have to change anything else?
As stated on another thread ... this MIGHT be a viable option. But
without actually trying it, it's difficult to say for sure.
I was able to successfully start Solr 8.11.0 after replacing its log4j
2.14.1 jars with 2.15.0. That's an upgrade of one minor version.
You're talking about upgrading across five minor versions. That's a lot
more likely to cause issues.
What I would recommend you do for a version that old is modify the
log4j-core jar in place to remove the JndiLookup class, as documented on
the log4j website.
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class
https://logging.apache.org/log4j/2.x/security.html
As for whether you need to do that for prometheus-exporter ... you would
only need to do that if you are actually using that program. You would
likely know if you're doing that, it doesn't get started unless somebody
runs it explicitly. Solr devs have stated that they do not think the
prometheus exporter is vulnerable, as it should never send any
user-created string to the logging implementation. But if you're using
it, it's better to do mitigation even if it's not vulnerable.
Thanks,
Shawn
