Security Bulletin: Vulnerability in Apache Log4j affects IBM Netcool Performance Manager

Summary

Apache-Log4j - CVE-2021-4104, Apache-Log4j - CVE-2022-23302, Apache-Log4j - CVE-2022-23305, Apache-Log4j - CVE-2022-23307

Vulnerability Details

Refer to the security bulletin(s) listed in the Remediation/Fixes section

Affected Products and Versions

Remediation/Fixes

Below are the CVE Details -

# Apache-Log4j - CVE-2021-4104 :
A flaw was found in the Java logging library Apache Log4j in version 1.x. JMSAppender in Log4j 1.x is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker’s JNDI LDAP endpoint.

# Apache-Log4j - CVE-2022-23302 :
A flaw was found in the Java logging library Apache Log4j in version 1.x. JMSSink in Log4j 1.x is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if JMSSink is deployed and has been configured to perform JNDI requests.

# Apache-Log4j - CVE-2022-23305 :
A flaw was found in the Java logging library Apache Log4j in version 1.x. JDBCAppender in Log4j 1.x is vulnerable to SQL injection in untrusted data. This allows a remote attacker to run SQL statements in the database if the deployed application is configured to use JDBCAppender with certain interpolation tokens.

# Apache-Log4j - CVE-2022-23307 :
A flaw was found in the log4j 1.x chainsaw component, where the contents of certain log entries are deserialized and possibly permit code execution. This flaw allows an attacker to send a malicious request with serialized data to the server to be deserialized when the chainsaw component is run.

These are the mitigation steps for the above mentioned issues :

• Comment out or remove JMSAppender, JMSSink, JDBCAppender in the Log4j configuration if it is used. There can be other log4j.xml files if configured additionally on customer’s environment apart from below mentioned xmls.[Here $WMCROOT=/appl/virtuo (Virtuo Directory)]

  1. $WMCROOT/as/server/default/conf/log4j.xml
  2. $WMCROOT/conf/logging/cli/log4j.xml

• Remove the JMSAppender, JMSSink, JDBCAppender class and Chainsaw classes from the classpath.

  1. Take backup of below used log4j jars

  2. Stop all the application services - as, asd, alarmcache, nccache and loader instances (as these components could be using log4j)

  3. Execute the following command -

  4. zip -q -d log4j*.jar org/apache/log4j/net/JMSAppender.class

  5. zip -q -d log4j*.jar org/apache/log4j/net/JMSSink.class

  6. zip -q -d log4j*.jar org/apache/log4j/jdbc/JDBCAppender.class

  7. zip -q -d log4j*.jar org/apache/log4j/chainsaw/*

  8. JMSAppender.class, JMSSink.class, JDBCAppender.class and Chainsaw classes can be found in following locations - [Here $WMCROOT=/appl/virtuo (Virtuo Directory)]

  9. $WMCROOT/as/client/log4j.jar

  10. $WMCROOT/as/lib/log4j-boot.jar

  11. $WMCROOT/as/server/default/lib/log4j.jar

  12. $WMCROOT/lib/tp/log4j.jar

  13. Start all the services which were stopped in step #2

• Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker.

Workarounds and Mitigations

For an external (e.g. internet facing) attacker to exploit the aforementioned vulnerabilities is likely to have less possibility as as the application is deployed on local servers.

Vulnerability components/classes mentioned previously are not enabled by default, are not used in our application, and can be disabled. So the attack vector is greatly reduced as it depends on an attacker having to write access to compromise the configuration. Additionally, the application admin can change user permissions of respective files and restrict users.