This does NOT need to be performed on systems prior to 7.3.0 that use Log4j 1.x 7.6.1 includes everything in these steps already with Log4j 2.17.0 version 7.6.2 includes everything in these steps already with Log4j 2.17.1 version This article includes Log4j 2.17.1 packages, however you do not need to update if you have already installed 7.6.1 or Log4j 2.17.0 as the class file was removed.
Open a terminal/ssh session to the backend.
Take a backup of the solr.in.sh file. This will be under /etc/cb/solr/ or /etc/cb/solr6/ directory
Run the following command(s) on all EDR servers (primary and minion if clustered):
7.3.0 - 7.5.2 (If you followed the original mitigation steps, this command does not need to be applied) CVE-2021-44228
sudo /bin/sh -c 'solr6=/etc/cb/solr6/solr.in.sh; solr=/etc/cb/solr/solr.in.sh; if [ -f $solr6 ]; then if ! grep -q "formatMsgNoLookups" $solr6; then echo SOLR_OPTS=\"\$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true\" >> $solr6; fi; elif [ -f $solr ]; then if ! grep -q "formatMsgNoLookups" $solr; then echo SOLR_OPTS=\"\$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true\" >> $solr; fi; fi'
7.3.0 - 7.6.0: To fix CVE-2021-45105, please follow the below instructions to patch Log4j to version 2.17.1, the files include the removal of JndiLookup.class for CVE-2021-45046 and CVE-2021-44832
Take a backup of the current files
sudo tar -cvzf /usr/share/cb/solr/server/lib/ext/log4j_backup.tar.gz /usr/share/cb/solr/server/lib/ext/log4j-* --remove-files
Copy the log4j_2_17.tar.gz on the primary (and minions if clustered) and extract them. Download here: log4j_2_17_1.tar.gz
sudo tar -xvf log4j_2_17_1.tar.gz -C /usr/share/cb/solr/server/lib/ext/
No, 7.6.1 includes Log4j version 2.17.0 with the fix, this version also includes both previous mitigations
What about older versions?
Older versions used log4j versions 1.x and therefore are not part of the vulnerability
What does the first command do?
The first command disable the formatMsgNoLookups feature that is vulnerable to exploit. This feature allows for potential for an attacker to gain access to the machine
It will check for proper folder location and add the config to the solr.in.sh file. If you added this previously or are on 7.6.0 it is not needed. The command did change slightly to account for not duplicating the config by accident if run again
What does the second command do?
Patches Log4j to 2.17.1 for Solr, the JndiLookup.class has been removed from the library of the included files.
Can I update Log4j?
Please see step 4. This should only be done for 7.3.0 to 7.6.0. Updating Log4j on any previous versions will cause issues with the Solr service
Do not update via yum as it will not update our package and will install other dependencies on the machine we do not use.
I'm an Hosted EDR customer. Is there anything I need to do?
Hosted EDR was updated to 7.6.0 with the first mitigation recommendation on 12/11 (CVE-2021-44228) and again on 12/15 to cover (CVE-2021-45046). On 12/23 the server was updated to 7.6.1 with Log4j version 2.17.0 to cover (CVE-2021-45105) and JNDILookup class was removed and covers (CVE-2021-44832)
What about CVE-2021-45105?
HEDR has been updated to 7.6.1 with Log4j version 2.17.0
7.6.1 with Log4j version is releasing 12/23
What about CVE-2021-44832?
7.6.1 and replacement 2.17.0 included a version with JNDILookup class removed. The product does not use the JDBC Appender and does not work without the JNDILookup class
If you have already installed 7.6.1 or followed the instructions for 2.17.0, you do not need to update to 2.17.1 unless your internal security practices require this version.
What are the checksums for the log4j_2_17_1.tar.gz and contents?