DX UIM and log4j2 vulnerabilities: CVE-2021-44228, CVE 2021-45046, CVE-2021-45105, CVE-2021-4104
Article ID: 230333
Updated On:
Products
Issue/Introduction
- CVE-2021-44228: In Apache Log4j versions >=2.0-beta9 and <=2.14.1, JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
- Additionally, CVE-2021-45046 was reported to affect log4j version 2.15 as the original fix for CVE-2021-44228 which was included in 2.15 only partly resolves the issue. Version 2.16 has been released as a result.
- A third vulnerability, CVE-2021-45105 was reported to affect Log4j2 versions through 2.16.0 which allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted.
- This document contains mitigation steps for CVEs 2021-44228 and 2021-45046. DX UIM is *NOT* impacted by CVE-2021-45105.
- The same hotfixes apply to both. If you have already applied these hotfixes for CVE-2021-44228, then you are already also protected from CVE-2021-45046.
- CVE-2021-4104: This CVE refers to a deserialization of untrusted data vulnerability in the JMSAppender in older versions of Apache Log4j 1.x. This vulnerability was disclosed during investigations related to Log4Shell (CVE-2021-44228). (There are no critical or high severity vulnerabilities on sap_basis 2.22 and later)
PLEASE NOTE: Once you have applied the hotfixes successfully, we recommend deleting old/vulnerable probe versions from your DX UIM Archive(s) to prevent someone from inadvertently redeploying a vulnerable version in the future. This includes remote hub archives in cases where package forwarding is enabled.
Environment
DX UIM Releases 20.3.*, 20.4.*, 23.4.*
Cause
These vulnerabilities affect all versions of log4j from 2.0-beta9 to 2.15.
Resolution
- DX UIM 23.4.* is not vulnerable to CVE-2021-44228, CVE 2021-45046, CVE-2021-45105, CVE-2021-4104
- DX UIM 20.4 was released with log4j 2.16. Below you can find hotfixes to update core components to log4j 2.17 as well) the following solution documents provide links to the available hotfixes. (Be sure to login so that the download links become available)
UIM Core/Infrastructure components: Solution Document LU04071 (Now with log4j 2.17!)
UIM Monitoring And Gateway Probes: Solution Document LU04025
- DX UIM 20.4 Operator Console (OC) Operator Console 20.4 CU3 replaces all LOG4J 2.x AND 1.X LIBRARIES with 2.17.1
- DX UIM prior to 20.4 is vulnerable to both CVEs 2021-44228 and 2021-45046.
- For UIM CABI (including references to the 'buildomatic' folder) see the following KB: KB231415
Note: Prior solution document "LU03862" also contains older hotfixes for some UIM core probes. These hotfixes have been replaced by those provided on LU04071, but they are still sufficient to mitigate the vulnerabilities.
- For DX UIM 20.3.3 and 20.4.*
The below probes bundled in UIM installation are packaging log4j-core version 2.0 and above.
-
- automated_deployment_engine
- baseline_engine
- ems
- ppm
- prediction_engine
- uimapi
- webservices_rest
For the above probes, apply the fixes for the appropriate version of UIM from Solution Document LU04071
For all other monitoring and gateway probes, hotfixes can be obtained from Solution Document LU04025
Note: No further steps are required for these hotfixes - simply deploy them over your existing versions and that is sufficient to mitigate these vulnerabilities.
===============================================================================================================================
IMPORTANT
PLEASE NOTE: This vulnerability requires not only for the affected jar file to be present, but for the log4j system to be "externalized" - in other words, it must be possible for an attacker to force a particular sequence to be written directly to the logs. The mere "presence" of the jar file within a probe directory does *NOT* indicate that that probe is vulnerable. In most cases, the logging is NOT externalized for UIM monitoring probes; externalized logging for UIM is done through an internally developed log system which does not rely on log4j, and the presence of the log4j2-core*.jar file is not enough to render the probe vulnerable.
As a proactive measure we have released hotfixes for UIM monitoring and gateway probes: Solution Document LU04025
Many of these hotfixes are bundled with a log4j-core*jar with the JNDILookup.class removed which mitigates the vulnerability.
Please note also that some security scan software may still flag a vulnerability due to the presence of the log4j-core-2.x files; this should be considered a false positive if the log4j-core*.jar file was detected in one of the probes for which you have already applied the hotfixes / mitigated the vulnerability.
Applying the fixes in this KB is considered sufficient to mitigate the vulnerability and should be taken as an immediate security measure. For the future, we are currently planning to upgrade all UIM probes to log4j 2.17 to avoid triggering any scans but this is a longer-term effort and as of this writing (December 2021) we do not have an ETA.
===============================================================================================================================
Additional Information
PRIOR RELEASES OF UIM (pre-20.3:)
Currently UIM releases 20.1 and prior are considered End-of-Life and not supported; we encourage you to upgrade to a supported release immediately.
That being said, if you need to mitigate this vulnerability on a prior version of UIM you will need to do it manually as hotfixes will not be published.
Steps are as follows:
- baseline_engine: Navigate to location-> <NimsoftInstallationDirectory>\Nimsoft\probes\slm\baseline_engine\lib
- log4j-core-2.5.jar needs to be extracted to remove class (Path: org/apache/logging/core/lookup).
- After removing class, re-package log4j-core-2.5.jar
- Place the re-packaged jar without .class file under the same location (<NimsoftInstallationDirectory>\Nimsoft\probes\slm\baseline_engine\lib)
- Restart the baseline_engine probe
- prediction_engine: Navigate to-> <NimsoftInstallationDirectory>\Nimsoft\probes\slm\prediction_engine\lib
- Repeat the same steps.
- automated_deployment_engine: Navigate to-> <NimsoftInstallationDirectory>\Nimsoft\probes\service\automated_deployment_engine\lib
- Repeat the same steps, but in this case log4j-core-2.7.jar is used instead of 2.5.
- For other probes not listed above, please consult the solution documents above for the latest hotfixes. Monitoring/gateway probe hotfixes from Solution Document L04025 should work on any UIM version.
Note: the same steps can generally be followed for custom probes, but the developers should be consulted for permanent mitigation.
|
If you find the JNDILookup.class file in any other probes, it is safe to remove it, but care must be taken to fully preserve the folder structure of the jar file(s). For UIM probes we do not recommend manual mitigation, you should apply the hotfixes, but it may be necessary for custom probes. If you have any trouble removing the file because it is locked, the robot may need to be stopped before you try to remove the file. If the robot is stopped and the JNDILookup.class file remains locked, set the robot to manual startup, then reboot the machine, then when the system is back up, remove the file, then start the robot and reset it to Automatic Start. |
HOW TO ACCOMPLISH STEPS 2-4:
Windows:
- Stop the probe in question, or stop the robot watcher service
- Rename the .jar file to .zip
- Double-click the file to navigate into the folder structure of the zip file
- Locate the JNDILookup.class using the path information above, and delete the file
- Back out and rename .zip back to .jar
- Start the probe or service
Linux:
- Stop the probe or nimbus service
- Navigate to the folder where the .jar file is located
- Run the following command
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Start the probe/service
CVE Details:
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://nvd.nist.gov/vuln/detail/CVE-2021-45046
https://nvd.nist.gov/vuln/detail/CVE-2021-45105
FREQUENTLY ASKED QUESTIONS
=============================================================================================================================
Q: Even though we have applied the hotfixes, our security scan software reports that we still have the vulnerability. How can this be addressed?
A: This may occur if the scanner is checking simply based on the filename/version number; upgrading to DX UIM 20.4 with log4j 2.16 should help, but if you have applied the hotfixes/mitigations described in this KB, these should be considered false positives.
Q: Will probes be released for UIM 20.3x that contain the updated log4j version, so that we can avoid triggering our security scans?
A: For UIM Infrastructure Probes, we have released probes for both 20.3x and 20.4 that contain log4j 2.17 and these are available on Solution Document LU04071
For UIM monitoring probes, we may evaluate upgrading to log4j 2.17 on a case-by-case basis as the probes receive regular upgrades. For now we have released hotfixes which mitigate these vulnerabilities through the removal of JNDILookup.class from log4j-core*.jar. Solution Document L04025.
Q: DX UIM 20.4 ships with log4j 2.16 but there has since been another update. Will a patch/update be released that contains log4j 2.17 (or higher if necessary)?
A: As mentioned above we have released patches for UIM 20.4 and 20.3x containing log4j 2.17. Solution Document LU04071
Q: What about log4j 2.17.1? Isn't there a vulnerability in 2.17.0?
A: The vulnerability in question, CVE-2021-44832, is classified as "Medium" and for DX UIM is considered LOW risk. We plan to update to log4j 2.17.1 (or whatever might be available next) as part of the regularly planned and scheduled probe updates. No hotfixes will be released for this vulnerability per Broadcom policy, but you should update to the latest available probe versions as they are released.
As of January 25, 2022, the following probes have been released to General Availability with log4j 2.17.1:
- aws v5.42
- ceph 1.24
- cisco_ucs 2.52
- clariion v2.25
- cohesity 1.0.1
- ecometer 5.12
- hitachi 2.14
- icmp 1.27
- messagegtw v1.46
- netapp_ontap 1.24
- nic_monitor v1.3
- nutanix_monitor v1.59
- purestorage 1.24
- sap_basis 2.09 (sap_basis 2.22 Blackduck vulnerabilities remediated)
- vmware 7.1.7
- xendesktop 4.26
- xtremio 1.03
Q: Some probes are using log4j 1.x - do we need to worry? Isn't there a vulnerability here too?
A: UIM's implementation of log4j 1.x does not use JMSAppender which is a required component of the known vulnerability and therefore UIM is not impacted.
Q. snmpcollector v4.04x is still showing up on a vulnerability scan as a log4j vulnerability. Is there an updated version?
As of February 21,2022 the Log4j library for snmpcollector has been updated to 2.17.1 to remediate the vulnerabilities - CVE-2021-44228, CVE 2021-45046, and CVE-2021-45105.
snmpcollector v4.05 is available from the http://support.nimsoft.com website probe archive for download.
Q: Is sap_basis probe vulnerable to CVE-2021-4104?
A: All the Blackduck vulnerabilities including log4j are remediated in sap_basis 2.22 version and later. There are no critical or high severity vulnerabilities on sap_basis 2.22.
=============================================================================================================================
Feedback
