RHSA-2021:5094MediumCVSS 9.8

Red Hat Security Advisory: OpenShift Container Platform 3.11.z security update

Published
December 14, 2021
Last Modified
August 2, 2026

🔗 CVE IDs covered (2)

CVE-2021-44228 →CVE-2021-45046 →

📋 Description

CVE-2021-44228 — log4j-core: Remote code execution in Log4j 2.x when logs contain an attacker-controlled string value CVE-2021-45046 — log4j-core: DoS in log4j 2.x with thread context message pattern and context lookup pattern (incomplete fix for CVE-2021-44228)

🎯 Affected products2

  • Red Hat OpenShift Container Platform 3.11
  • openshift3/ose-logging-elasticsearch5@sha256:88379eab3d1e07f120b5dc6fa6ba4ebf96d3afb6aaf388d279084d675b23b5c2_amd64 as a component of Red Hat OpenShift Container Platform 3.11

✅ Remediation

See the following documentation, which will be updated shortly for release 3.11.z, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html This update is available via the Red Hat Network. Details on how to use the Red Hat Network to apply this update are available at https://access.redhat.com/articles/11258 . Workaround: For Log4j versions >=2.10 set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true For Log4j versions >=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 >=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 Workaround: For Log4j versions up to and including 2.15.0, this issue can be mitigated by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

🔗 References (5)