- Notice: On December 14, 2021 the Apache Software Foundation notified the community that their initial guidance for CVE-2021-44228 workarounds was not sufficient. We believe the instructions in this article to be an effective mitigation for CVE-2021-44228, but in the best interest of our customers we must assume this workaround may not adequately address all attack vectors.
- We expect to fully address both CVE-2021-44228 and CVE-2021-45046 by updating log4j to version 2.16 in forthcoming releases of vRealize Log Insight, as outlined by our software support policies. VMSA-2021-0028 will be updated when these releases are available. In the interim, we will be updating this Knowledge Base article with revised guidance to remove all JndiLookup classes per Apache Software Foundation guidance.
- CVE-2021-44228 and CVE-2021-45046 have been determined to be present in vRealize Log Insight versions 8.1.1 – 8.6 via the Apache Log4j open source component it ships.
- This vulnerability and its impact on VMware products are documented in the following VMware Security Advisory (VMSA). Please review this document before continuing: VMSA-2021-0028.
Impact / Risks
- It is highly recommended to take snapshots of the vRealize Log Insight nodes.
- The workaround described in this document is meant to be a temporary solution only.
- Upgrades documented in the aforementioned advisory should be applied to remediate CVE-2021-44228 and CVE-2021-45046 when they become available.
Notice: The below content has been updated as of 12/16/2021 to add workaround steps for the related CVE-2021-45046 as noted above. Please run all the steps below even if you have already implemented the original CVE-2021-44228 workaround steps by running the “li-log4j-fix.sh” script.
To apply the workaround for CVE-2021-44228 and CVE-2021-45046 to vRealize Log Insight, perform the following steps for each vRealize Log Insight node in the cluster:
- Copy the attached li-log4j-fix.tar.gz file to the /tmp directory using a utility like WinSCP or FileZilla
- Log into the node as root via SSH or Console, pressing ALT+F1 in a Console to log in.
- Change to the /tmp directory on all nodes
- Untar the li-log4j-fix.tar.gz file
- Run the following commands to make the li-log4j-fix-def.sh and li-log4j-fix-class.sh scripts executables:
chmod +x li-log4j-fix-class.sh
- Run the following commands on all nodes to execute the scripts:
- Restart the vRealize Log Insight service:
- Make sure that the service is up before proceeding to the next node
service loginsight status
Note: If the service is running, you will see the following in the output from the above command:
Active: active (exited)
Verify the workaround
To verify the workarounds for CVE-2021-44228 and CVE-2021-45046 have been correctly applied to vRealize Log Insight, perform the following steps:
- Log into each node as root via SSH or Console, pressing ALT+F1 in a Console to log in
- Run the following command to verify if the workaround was successful:
If there was no output on any particular node(s), that node(s) was not successfully modified.
Re-run the script on that node(s) following the instructions above and check again for output.
- Re-run the li-log4j-fix-class.sh to re-check:
Note: The following output is expected if the workaround was successfully applied:
Searching for impacted .jar files. Please wait…
No impacted .jar files found
- December 15th 2021 – 11:30am PST:
- Added external links to WinSCP and Filezilla, made formatting edits to workaround steps
- Added related article links to workaround steps which if encountered, may inhibit the workaround from being run.
- December 16th 2021 – 10:45am PST:
- Added statement from Apache that their initial guidance released on 12/14 was not effective.
- Updated affected versions to include 8.1.1.
- Updated to include workaround for CVE-2021-45046.
- December 17th 2021 – 7:33am PST:
- Added statement that vRealize Log Insight 4.x, 8.0, and 8.1 are not affected.