Dear ONAP Community, A new variant of the APACHE log4j vulnerability has been identified.
The only approved mitigation technique moving forward will be class removal or patch to 2.16. Background We have been notified of a new Zero day impacting nearly all Apache software versions where a logging package named Log4j between versions 2.0 through 2.15 allows REMOTE attackers to add malicious code and then execute this code. This is an extremely dangerous vulnerability that can allow attackers the ability to take control of a server. Helpful Links/References Details of the vulnerability can be found at this CVE site: CVE - CVE-2021-44228 (mitre.org)<https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228> Mitigation - https://logging.apache.org/log4j/2.x/download.html Frequently Asked Questions/Issues 1. What versions of Log4J are vulnerable? Log4j between versions 2.0 through 2.15 are vulnerable. Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability. 2. What can be done to mitigate the vulnerability? Answer: Complete one of these options now Implement one of the mitigation techniques below. Preferred method o Java 8 (or later) users should upgrade to release 2.16.0. Temporary mitigation- o Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. o Restart the application Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability. In addition to the above, for Azure apps you must enable OWASP rules on the WAF. Deprecated mitigation techniques (Please see question # 4) These are no longer valid. This document mentioned the following mitigation options that were discovered to only limit exposure while leaving some attack vectors open. Option 1-This mitigation is only available for log4j versions between 2.10 and 2.14 Set system property log4j2.formatMsgNoLookups to true Option 3- JDK mitigations - the JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not impacted as long as the default configs for the following are not modified o com.sun.jndi.ldap.object.trustURLCodebase=false o com.sun.jndi.cosnaming.object.trustURLCodebase=false o com.sun.jndi.rmi.object.trustURLCodebase=false Applications implementing these older mitigation techniques will need to adhere to the revised mitigation guidance (listed above) to be considered compliant with the CSO guidelines for log4j vulnerability mitigation. Note: Mitigation options need to be validated in a test environment before deploying to production. 3. Why am I being asked to mitigate again when I already implemented recommended mitigations? The following older mitigation options were discovered to only limit exposure while leaving some attack vectors open. Option 1- This mitigation is only available for log4j versions between 2.10 and 2.14 Set system property log4j2.formatMsgNoLookups to true Option 3- JDK mitigations - the JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not impacted as long as the default configs for the following are not modified o com.sun.jndi.ldap.object.trustURLCodebase=false o com.sun.jndi.cosnaming.object.trustURLCodebase=false o com.sun.jndi.rmi.object.trustURLCodebase=false Applications implementing the older mitigation techniques will need to adhere to the revised mitigation guidance from question 3 to be considered compliant with the CSO guidelines for log4j vulnerability mitigation. 4. What can be done to mitigate a transitive package? Answer: The following mitigation options can be considered for mitigation of a transitive log4j package. Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class 5. Why is my application in the impacted list, I am not using log4j packages? Answer: Your app may be using log4j as a transitive package that you do not have visibility to. 6. How do I upgrade Log4j library to a non-vulnerable version? Answer: Refer to the link below for guidance on upgrading Log4j to 2.16 https://logging.apache.org/log4j/2.x/download.html Note: This is a fairly new version, and has not been sufficiently tested. Problems have been reported when applications compiled with 2.16.0 version. 7. Am I Vulnerable if I am using Log4j 1.x? Answer If using Log4j 1.x, you are impacted by this vulnerability only if you are using JMS Appenders. To verify if you are using this appender, double check your log4j configuration files for presence of org.apache.log4j.net.JMSAppender class. Having said this, Log4j 1.x has reached end-of-life as of August 2015 and patches are no longer available. It has its own set of remote code execution issues and should be updated. 8. Do I need to remediate if the app moved to Azure? Answer Yes, enabling OWASP rules on the WAF is the first step, but WAF protections are only temporary and all apps with vulnerable package are required to remediate according to mitigation options listed above. Best regards, Catherine -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8347): https://lists.onap.org/g/onap-tsc/message/8347 Mute This Topic: https://lists.onap.org/mt/87700194/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/21656/1412191262/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
