RHSB-2021-009 Log4Shell - Remote Code Execution - log4j (CVE-2021-44228)

Executive summary

Apache Log4j is a library for logging functionality in Java-based applications. 

A flaw was found in Apache Log4j v2 (an upgrade to Log4j), allowing a remote attacker to execute code on the server if the system logs an attacker-controlled string value with the attacker's Java Naming and Directory Interface™ (JNDI) Lightweight Directory Access Protocol (LDAP) server lookup. This flaw allows a remote attacker to execute code on the target system with the same privileges as the Java-based application that invoked Apache Log4j v2. 

This issue has been assigned CVE-2021-44228 and rated with a severity impact of Critical.

The following products are NOT affected by this flaw and have been explicitly listed here for the benefit of our customers.

• Red Hat Enterprise Linux

• Red Hat Advanced Cluster Management for Kubernetes 

• Red Hat Advanced Cluster Security for Kubernetes

• Red Hat Ansible Automation Platform (Engine and Tower)

• Red Hat Certificate System

• Red Hat Directory Server

• Red Hat Identity Management

• Red Hat CloudForms 

• Red Hat Update Infrastructure

• Red Hat Satellite

• Red Hat Ceph Storage

• Red Hat Gluster Storage

• Red Hat OpenShift Data Foundation

• Red Hat OpenStack Platform

• Red Hat Virtualization

• Red Hat Single Sign-On

• Red Hat 3scale API Management

Technical summary

A flaw was found in the Java logging library Apache Log4j in versions from 2.0.0 and before 2.15.0. A remote attacker who can control log messages or log message parameters can execute arbitrary code on the server via the JNDI LDAP endpoint. Refer to CVE-2021-44228 for more details.

Mitigation

For Log4j versions 2.10 and later:

• set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true

For Log4j versions between 2.7 and 2.14.1:

• all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m

For Log4j versions between 2.0-beta9 and 2.10.0:

• remove the JndiLookup class from the classpath. For example: 

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

On OpenShift 4 and in OpenShift Logging, the above mitigation can be applied by following the steps in this article: https://access.redhat.com/solutions/6578421

On OpenShift 3.11, mitigation to the affected Elasticsearch component can be applied by following the steps in this article: https://access.redhat.com/solutions/6578441

Technical details

A flaw was found in the Java logging library Apache Log4j in versions from 2.0.0 and before 2.15.0. A remote attacker who can control log messages or log message parameters can execute arbitrary code on the server via the JNDI LDAP endpoint.

This issue only affects log4j versions between 2.0 and 2.14.1. To exploit this flaw you need:

• A remotely accessible endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send arbitrary data,

• A log statement in the endpoint that logs the attacker controlled data.

Impact On Cloud Services

The impact of CVE-2021-44228 and related log4j vulnerabilities disclosed to date have been assessed for all cloud services.  Those identified as potentially affected were addressed immediately. Usage of the vulnerable component and the potential exposure varied across services. Red Hat has applied mitigations (see above), patches, and in some cases, removed the vulnerable component to address the risk in a timely manner.

Red Hat continues to monitor the potential impact of these vulnerabilities on Red Hat cloud services and works with 3rd parties as necessary, to provide assurance around our services.  Further communications will be issued as required.

Updates for affected products

Red Hat customers running affected versions of these Red Hat products are strongly recommended to update as soon as errata are available. Customers are urged to apply the available updates immediately and enable the mitigations as they deem appropriate.  

[1] Advisory/Update link will be added once updates are live.

Diagnose

A vulnerability detection script has been developed to determine if your system is currently vulnerable to this flaw. To verify the authenticity of the script, you can download the detached GPG signature as well. Instructions on how to use GPG signatures for verification are available on the Customer Portal.

Ansible Playbook

Additionally, an Ansible playbook is available to run the detection script on many hosts at once. The playbook requires an additional vars file, which controls its operation. Detached GPG signatures are available for the playbook and its vars file. After downloading the playbook and its associated vars file, edit the vars file to tailor it to your environment. 

You should specify:

detector_path: The path the detection script will scan for vulnerable archives.

detector_dir: The playbook will copy the detection script to this directory on remote hosts.

detector_run_dir: The path the detection script will use for temporary storage.

To run the playbook, you will need to specify two extra vars on the command line:

HOSTS: The host(s) or group(s) to scan, as defined in your Ansible inventory.

vars_file: The path to the vars file.

For example:

# ansible-playbook -e HOSTS=all -e vars_file=log4j-cve-2021-44228-vars.yml log4j-cve-2021-44228.yml

FAQ

Q: Do we need to restart a service or an application after applying security fixes or mitigations? If yes, which ones?  

A: While it is best practice and recommended to restart your service or application,  it depends on the application deployment strategy; for example: 

• In Java-based applications, yes, the application servers must be restarted after applying the security fix.

Q. In Red Hat OpenShift products (including OpenShift Logging), it is necessary to accept updates once they are available? 

1. To read more about the OpenShift Container Platform and OpenShift Logging update process, use the following guide for reference:

• Understanding the OpenShift Update Service

• Updating OpenShift Logging

Q: Are services like ARO/OSD/ROSA vulnerable? 

A: No, per the reasons cited here: 

Apache log4j2 Remote Code Execution (RCE) Vulnerability

Q: After I apply the Log4j v2 updates mentioned above, do I still need to wait for the Security Errata to release in CVE-2021-45046, CVE-2021-45105 and CVE-2021-44832?

A: No, you do not have to wait for new releases in CVE-2021-45046, CVE-2021-45105 and CVE-2021-44832. These CVEs are MODERATE Severity Impact issues. Unless you use a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}) in your product's Log4J configuration (which is not configured by default and out-of-box in Red Hat Products), you are not vulnerable to these issues.

Q: Some Red Hat products ship Log4j v1. Do the updates mentioned in this Security Bulletin fix the vulnerabilities in Log4j v1 as well?

A: Log4j version 1.x is NOT affected by CVE-2021-44228 (Log4Shell). For Log4j v1.x, there are separate known issues depending on the affected libraries or components as mentioned below, and most of them are NOT affected when used with the default configuration.

• CVE-2021-4104 (Log4j v1.x JMSAppender) has a severity impact rating of Moderate. Log4j v1.2 is vulnerable to deserialization of untrusted data when either the attacker has write access to the Log4j configuration or is configured to use JMSAppender with specific options enabled, which is not the default configuration. 

• CVE-2022-23302 (Log4j v1.x JMSSink) has a severity impact rating of Moderate. Log4j v1.x is vulnerable to deserialization of untrusted data. This flaw ONLY affects applications that are specifically configured to use JMSSink, which is not the default, or when the attacker has write access to the Log4j configuration for adding JMSSink to the attacker's JNDI LDAP endpoint.

• CVE-2022-23305 (Log4j v1.x JDBCAppender) has a severity impact rating of Important. JDBCAppender in Log4j v1.x is vulnerable to SQL injection in untrusted data. Note this issue only affects Log4j v1.x when specifically configured to use the JDBCAppender, which is not the default.

• CVE-2022-23307 (Log4j v1.x Chainsaw) has a severity impact rating of Important. A flaw was found in the log4j v1.x chainsaw component, where the contents of certain log entries are deserialized and possibly permit code execution. Chainsaw is a standalone graphical user interface for viewing log entries in log4j. This flaw may be avoided by using other available means to access log entries.

Please refer to individual CVE pages for more details. 

References

• Remote code injection in Log4j - Github 

• Apache Log4j Security Vulnerabilities

• Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package