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.
Product | Component(s) | Advisory / Update |
Red Hat CodeReady Studio 12 | log4j-core | |
Red Hat Enterprise Application Platform 7 | log4j-core | |
Red Hat Integration Camel K | log4j-core | |
Red Hat Integration Camel Quarkus | log4j-core | |
Red Hat OpenShift Application Runtimes Vert.X 4 | log4j-core | |
Red Hat Fuse 7 | log4j-core | |
Red Hat OpenShift 4 | hive-container presto-container logging-elasticsearch6-container | |
Red Hat OpenShift 3.11 | logging-elasticsearch5-container | |
Red Hat OpenShift Logging | logging-elasticsearch6-container | |
Red Hat Data Grid 8 | log4j-core | |
Red Hat AMQ Streams | log4j-core | |
Red Hat OpenStack Platform 13 | opendaylight | End Of Life |
Red Hat Process Automation Manager | log4j-core |
[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?
To read more about the OpenShift Container Platform and OpenShift Logging update process, use the following guide for reference:
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
Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package
46 Comments
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.
Current Customers and Partners
Log in for full access
Log InNew to Red Hat?
Learn more about Red Hat subscriptions
So does this affect RHEL7? The statement at https://access.redhat.com/security/cve/cve-2021-44228 makes it sound like log4j 1.2 in RHEL7 might be impacted.
RHEL7 is not affected.
This seems incorrect. The table above has a column "Log4j v1" under which most of the products are listed with the note [1]: "Advisory/Update link will be added once updates are live."
Hi RHEL 7 is not impacted by CVE-2021-44228 - which is also known as Log4Shell - and a Critical severity RCE flaw within log4j version 2.
RHEL 7 does ship an older version of log4j, version 1. Log4j version 2 was a re-write /new code base - and log4j v1 is not impacted by CVE-2021-44228. After a investigation it was determined that version 1 of log4j has a similar concern if the system is setup/configured in a specific manner (which is not the default in RHEL 7).
This new CVE - tracked as CVE-2021-4104 is rated as a Moderate, due to the complexity required. If you have configured log4j v1 with JMSAppender, allowing TopicBindingName or TopicConnectionFactorBindingName, then you are potentially exposed to this CVE and should remove those settings. If you have changed the default filesystem permissions such that tomcat can write to the configuration file (rather then default read-only access), then if an attacker finds a way to force the application to write to the config file - they could use reconfigure the application and expose this secondary Moderate CVE (CVE-2021-4104) - but if an attacker can write to your applications configuration file, you have a lot more concerns than the log4j v1 Moderate CVE to worry about.
Hopefully this explanation of why RHEL 7 is not impacted helps. We've tried hard to explain the differences between the impact of log4j v1 (Moderate, CVE-2021-4104) vs log4j v2 (Critical, CVE-2021-44228).
Regards,
Please review your services (probably with respective OEMs) hosted on the systems using RHEL 7.
Though RHEL may not be vulnerable to this exploit, the configuration of the services (application, database, etc.) might be.
Regards.
does this affect RHEL8?
RHEL8 is not affected.
Please review your services (probably with respective OEMs) hosted on the systems using RHEL 8.
Though RHEL may not be vulnerable to this exploit, the configuration of the services (application, database, etc.) might be.
Regards.
Does this affect Openshift that runs coreOS in anyway?
At least for openshift-logging it does & there is a workaround available - https://access.redhat.com/solutions/6578421
Is there a workaround similar for OpenShift 3? This article relates to OpenShift 4
https://access.redhat.com/solutions/6578441
Hi, Does this affect RHPAM in anyway?
Hello-- RHPAM does not directly use the vulnerable code but does ship it in Dashbuilder. So it is not vulnerable, but is affected at Low impact.
We do have redhat 5,6,7&8 in which version it will effect . We do have apache running on them . Any ETA for patch release .
Hi, RHEL is not impacted by this CVE.
Repeating myself: This seems incorrect. The table above has a column "Log4j v1" under which most of the products are listed with the note [1]: "Advisory/Update link will be added once updates are live."
Hi RHEL 7 is not impacted by CVE-2021-44228 - which is also known as Log4Shell - and a Critical severity RCE flaw within log4j version 2. RHEL 7 does ship an older version of log4j, version 1. Log4j version 2 was a re-write /new code base - and log4j v1 is not impacted by CVE-2021-44228. After a investigation it was determined that version 1 of log4j has a similar concern if the system is setup/configured in a specific manner (which is not the default in RHEL 7). This new CVE - tracked as CVE-2021-4104 is rated as a Moderate, due to the complexity required. If you have configured log4j v1 with JMSAppender, allowing TopicBindingName or TopicConnectionFactorBindingName, then you are potentially exposed to this CVE and should remove those settings. If you have changed the default filesystem permissions such that tomcat can write to the configuration file (rather then default read-only access), then if an attacker finds a way to force the application to write to the config file - they could use reconfigure the application and expose this secondary Moderate CVE (CVE-2021-4104) - but if an attacker can write to your applications configuration file, you have a lot more concerns than the log4j v1 Moderate CVE to worry about. Hopefully this explanation of why RHEL 7 is not impacted helps. We've tried hard to explain the differences between the impact of log4j v1 (Moderate, CVE-2021-4104) vs log4j v2 (Critical, CVE-2021-44228). Regards,
On my systems(closed network) with Red Hat Enterprise Linux Server that had log4j 1.2.17, I removed(via yum). Now I need to install log4j 2.17.1 on one of the servers. How do I install log4j 2.17.1 when it is not available on the Red Hat repository? Apache installation instructions are not clear and the Redhat repository still have only log4j 1.2.17 available.
Does it affect Ansible Tower?
Red Hat Ansible Automation Platform (Engine and Tower) - Not Affected.
What about log4j included in Satellite log4j-1.2.17-16.el7_4.noarch ? Satellite is not inlcuded inthe affected products.
https://access.redhat.com/solutions/6579781
Does this affect apache tomcat service which uses log4j library?
Potentially, yes. If the java application running tomcat is using log4j version 2 (such as log4j-core or log4j-api) you can be exposed to this. Within the RHEL tomcat, RHEL ships an older log4j version 1 which isn't exposed to the Critical CVE. log4j v1 (Moderate, CVE-2021-4104) vs log4j v2 (Critical, CVE-2021-44228)
Please provide updates for affected products - Red Hat JBoss Fuse 7 .
Hi - Fuse 7 released an update for this issue on Tuesday - please see - https://access.redhat.com/errata/RHSA-2021:5134 Regards,
From what I can see in the OSS projects, both Quarkus and Camel say they are not affected, but in this list from RedHat I see "Red Hat Integration Camel Extensions for Quarkus" listed as affected. Which Camel extensions for Quarkus are affected exactly?
Hi, Red Hat Integration Camel Extensions for Quarkus is the name of the bundled production of upstream components the we support for the Red Hat product. Red Hat Integration Camel Extensions for Quarkus as a product, ships the affected Log4j library. Red Hat doesn’t provide an “Standalone” Camel.
Does it affect RHEL 5
Hi, we will be updating this article soon. RHEL 5 is not impacted by this CVE.
Does this affect Red Hat JBoss Enterprise Application Platform 7 in case of using standard JBoss Log Manager?
Only the Mavenized EAP distribution is affected - meaning, the package containing the CVE is present on that product. However, it is NOT exploitable, meaning, it is not vulnerable. It is important to stress that the standard EAP distributions (Zip file, RPM file or Container) are NOT affected or vulnerable to this CVE: Only the mavenized distribution.
Does this affect Red Hat Identity Management?
Hi (sorry for delay here) we updated the article earlier this week to list and confirm that Red Hat Identity Management is NOT affected by this issue. Regards.
If RHEL 7 and 8 are not affected then why does the above list of "NOT affected" products not include them?
Hi, we will be updating this article soon. RHEL is not impacted by this CVE. Earlier today we was trying to complete assessment of RHEL for the usage of version 1 of log4j. This Critical CVE impacts version 2 of log4k. This investigation for version 1 concluded earlier today that log4j v1 is not impacted by this CVE, but there was a different issue that was confirmed with different CVE assignment, rated Moderate.
Thank you. As you can imagine we are getting a lot of attention by upper management and security people.
RHSB-2021-009 Log4Shell mentions that the following are affected by cve-2021-44228. openshift4/ose-metering-presto openshift4/ose-metering-hive Is there a fix or work around for those? All I see is a work around for the elasticsearch logging.
+1
The last CVE for the
ose-metering
images is CVE-2021-4125, and it's included in latest version of OCP 4.6, 4.7 and 4.8. The metering vulnerability is not affecting OCP 4.9 as metering was removed from that release as shown in the OCP 4.9 release notes.This article says that RHEL Satellite is not impacted, but this file is showing up as impacted by scanners: /usr/share/tomcat/webapps/candlepin/WEB-INF/lib/log4j-over-slf4j-1.7.12.jar can someone at RedHat speak to this?
Bulletin is correct and Satellite is not impacted. Product select logback framework for logging hence log4j-over-slf4j is not affected by default. Please note that log4j-over-slf4j is not log4j. It is an abstraction for various logging frameworks (e.g. logback, log4j).
Please update on the 2 CVEs page if JBoss Web Server 3.x and 5.x is affected or not
Hi, Both are not affected by Log4Shell - Critical CVE-2021-44228
JWS version 3 is affected by the Moderate CVE-2021-4104 Log4J version 1 CVE . JWS version 5 is not affected by either CVEs
Does this effect RedHat SSO?
Pages