Because of CVE-2021-45105 and the release of log2j 2.17.0 this post and the script have been updated to log2j 2.17.0.
Round 2 - Mitigating CVE-2021-45046 Log4j for your Sitecore SOLR installs
In my previous post I've shared a PowerShell script that you can use to mitigate CVE-2021-44228 for your local Sitecore installs. In the last few days a there have been some updates shared on almost all websites that are talkin about the vulnerability. On the 13th of December Log4j 2.15.0 was released. The day after it became clear that 2.15.0 still had issues. To fix these issues they released 2.1~6~7.0.
Upgrade to log2j 2.1~6~7.0
I've tested this version by replacing the Jar files in Solr with Solr 8.4.0 (Sitecore 10.0.1) and 8.8.2 (Sitecore 10.2.0). Other versions might use a different version of Solr. There is one other important dependency (slf4j-api) that I did NOT update because it is already the correct version (slf4j-api-1.7.24.jar). The logs still appeared and I wasn't able to reproduce the jndi lookups anymore, even when I removed the mitigation step (the famous set SOLROPTS=%SOLROPTS% -Dlog4j2.formatMsgNoLookups=true) as described in my previous post.
Updating is quite easy. It requires, again, a PowerShell script to do this.
Use at your own risk
Please use this script at your own risk and tailor it to your needs! The script is not tested against Solr 6.6.2 which uses log2j 1.2.17!
In the script you can specify the exact version of log2j you want upgrade to. For now this is 2.1~6~7.0, if a newer version is released in the upcoming days/weeks/months you can just fill in the variables and you are all set to run it again.
Executing this script
The script can be found on my GitHub.
Running this script will require Administrator privileges. If you execute this script it will ask you for the drive letter where the solr instances are located. If you have installed Solr on your C drive and D drive you might run this twice. The script does the following things.
- Ask you for the drive letter
- Searches for Solr instances by looking for solr.in.cmd files!
- Downloads the archive for log2j
- Validates the download
- Extracts the download
- Determines the Servicename
- Checks if a service exists, if so it will stop it
- Checks the log2j path if upgrade is needed
- Updates log2j for Solr if needed
- Checks the prometheus-exporter if upgrade is needed
- Updates log2j for the prometheus-exporter if needed
- Starts the service if it was stopped
- Repeat steps 6 - 12 for each instance found.
- Removed the downloaded files
If an exception occurs this can be caused by files being in use. This happens if the script could not find a service corresponding with your Solr instance directory name. If you know of any of these situations you can fix those.
Any suggestions or modifications are welcome in the form of a Pull Request.
Have a great day.