CVE-2021-4104: Log4j 1.x Vulnerability Remediation in CA Service Virtualization

Products

• Service Virtualization

Issue/Introduction

CVE-2021-4104:

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.

Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.

Environment

All supported DevTest releases.

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.

Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability. 

This vulnerability ONLY affects applications which are specifically configured to use JMSAppender, which is not the default, or when the attacker has write access to the Log4j configuration for adding JMSAppender to the attacker's JMS Broker.

Log4j 1.x comes with JMSAppender which will perform a JNDI lookup if enabled in log4j's configuration file, i.e. log4j.properties or logging.properties or log4j.xml as shown in the below example:

log4j.appender.jms=org.apache.log4j.net.JMSAppender

log4j.appender.jms.InitialContextFactoryName=org.apache.activemq.jndi.ActiveMQInitialContextFactory

log4j.appender.jms.ProviderURL=tcp://{{server}}:61616

log4j.appender.jms.TopicBindingName=logTopic

log4j.appender.jms.TopicConnectionFactoryBindingName=ConnectionFactory

 

If the Log4j configuration is set TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228 Log4j 2.x, Log4j 1.x is vulnerable.

An attacker who ALREADY has write access to the log4j configuration file will need to add JMSAppender into the configuration poisoned with malicious connection parameters. Also, note that poisoning the configuration file is not enough. The attacker also needs to force log4j to reload its configuration file with the poisoned parameters. Given that log4j 1.x does not offer automatic reloading, the poisoned configuration file will typically only become effective at application restart.

Note: DevTest does not support configuring JMSAppender by default. However, it makes some sense to make the job of the attacker even harder by following the below remediation steps.

Cause

 Log4j 1.2 vulnerability CVE-2021-4104

Resolution

These are the possible mitigations for Log4j 1.x:

•  Audit your logging configuration file ”logging.properties“ to ensure it has no JMSAppender configured. Comment out or remove JMSAppender in the Log4j configuration if it is used.

For example:

#log4j.appender.jms=org.apache.log4j.net.JMSAppender

#log4j.appender.jms.InitialContextFactoryName=org.apache.activemq.jndi.ActiveMQInitialContextFactory

#log4j.appender.jms.ProviderURL=tcp://localhost:61616

#log4j.appender.jms.TopicBindingName=logTopic

#log4j.appender.jms.TopicConnectionFactoryBindingName=ConnectionFactory

• If using our Docker or Kubernetes images, please use the first bullet as a means to mitigate.  If using our 10.6 or 10.7 GA installers, you can remove the following classes from the log4j 1.x jar or classpath using any of the below mentioned methods:

- org/apache/log4j/net/JMSAppender.class

- org/apache/log4j/net/SocketServer.class

- org/apache/log4j/net/SimpleSocketServer.class

- org/apache/log4j/net/SMTPAppender$1.class

- org/apache/log4j/net/SMTPAppender.class

 

       a. Method # 1 (Manual)

Remove the above classes from the log4j 1.x jars manually using ‘zip’ or ‘jar’ commands and restart the DevTest services.

For example, run the following command to remove a class from log4j file:

zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

If you do not have access to 'zip', you can also use the 'jar' command.

#assuming log4j-1.2.17.jar exists in current directory

mkdir tmp

cd tmp

jar xvf ../log4j-1.2.17.jar

rm org/apache/log4j/net/JMSAppender.class

jar cvf ../log4j-1.2.17.jar .

Similarly run these commands to remove all the above mentioned classes from all the log4j jars based on the SV version. 

Note: SV 10.7.0 uses log4j-1.2.17-clouder1.jar and SV 10.6.0 uses log4j-1.2.17.jar and log4j-jboss-logmanager-1.1.4.Final.jar.

 

       b. Method # 2 (Patch)

Apply the attached log4j patched jars based on the SV version by following the steps mentioned in “README_STEPS.txt” inside the zip.

• Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker. In Unix-speak, they should be read-only for all users, including the owner. If possible, they should also be monitored against changes and unauthorized manipulation.

Note: The above steps also include the remediation of “CVE-2019-17571” vulnerability.