Mitigations for Log4J CVE-2021-44228 #209
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As noted in https://www.sentinelone.com/blog/cve-2021-44228-staying-secure-apache-log4j-vulnerability/ Setting the enviroment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
|
Updated with new release of Solr that includes Log4j 2.1.16 |
alxp
changed the title
alxp
changed the title
alxp
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Islandora/documentation#2007
Taking a number of steps to close up the Shell4J vulnurability on fresh and existingsystems provisioned via Ansible.
Release pull requests, etc.)
https://logging.apache.org/log4j/2.x/security.html
What does this Pull Request do?
As per the Apache notes in the Log4J CVE, setting an environment variable will turn off the remote lookup feature of Log4J's string formatter. This update sets this as a global environment on all servers.
Since there is some evidence this may not be sufficient, this PR also scans the filesystem and removes the JndiLookup class from any 2.x log4j-core JARs it finds.
What's new?
Added a task to set values in the /etc/environment global variable file.
Adds a variable list in the inventory that currently contains just this one needed value.
Tasks in the Solr role to scan for vulnurable Log4J Core JARs.
How should this be tested?
Either a fresh or existing Islandora instance created from a playbook, run this playbook.
Log in via SSH.
Check that the environment variable is set by running 'printing' and looking for LOG4J_FORMAT_MSG_NO_LOOKUPS is 'true'
Unzip a log4j JAR and verify that the JndiLookup.class file is gone:
Note that this was done after running provision on an existing site so the solr version is 8.6, not the current 8.11.1 which ships with a newer Log4J core JAR.
Additional Notes:
All instances of log4j*.jar on the Vagrant box are either 1.x (not great but not vulnerable to this particular exploit) or are 2.13, unless provisioned fresh since the Solr version bump to 8.11.1.
root@islandora8:/# sudo find . -name "log4j*.jar" ./opt/solr-8.6.0/contrib/prometheus-exporter/lib/log4j-core-2.13.2.jar ./opt/solr-8.6.0/contrib/prometheus-exporter/lib/log4j-slf4j-impl-2.13.2.jar ./opt/solr-8.6.0/contrib/prometheus-exporter/lib/log4j-api-2.13.2.jar ./opt/solr-8.6.0/server/lib/ext/log4j-web-2.13.2.jar ./opt/solr-8.6.0/server/lib/ext/log4j-core-2.13.2.jar ./opt/solr-8.6.0/server/lib/ext/log4j-slf4j-impl-2.13.2.jar ./opt/solr-8.6.0/server/lib/ext/log4j-1.2-api-2.13.2.jar ./opt/solr-8.6.0/server/lib/ext/log4j-api-2.13.2.jar ./opt/fits-1.4.1/lib/droid/log4j-1.2.13.jar ./opt/fits-1.4.1/lib/log4j-1.2.17.jar ./opt/activemq/lib/optional/log4j-1.2.17.jar ./var/lib/tomcat9/webapps/bigdata/WEB-INF/lib/log4j-1.2.17.jar ./var/lib/tomcat9/webapps/fits/WEB-INF/lib/log4j-1.2.17.jar ./root/.gradle/wrapper/dists/gradle-5.0-all/4mxuau4c77thx8zlvtz4xiez7/gradle-5.0/samples/userguide/antMigration/fileDeps/groovy/libs/log4j-1.2.8.jar ./root/.gradle/wrapper/dists/gradle-5.0-all/4mxuau4c77thx8zlvtz4xiez7/gradle-5.0/samples/userguide/antMigration/fileDeps/kotlin/libs/log4j-1.2.8.jarThe change in the tomcat role is to fix a deprecation in Ansible's syntax that was preventing me from running the playbook on my homebrew's Ansible v. 2.12.
Interested parties
, @Islandora-Devops/committers