Bug 2030932 (CVE-2021-44228)

Created log4j tracking bugs for this issue:

Affects: fedora-all [bug 2030945]

Upstream patch: https://github.com/apache/logging-log4j2/pull/608/commits
Pull request: https://github.com/apache/logging-log4j2/pull/608

Another case was opened for this issue. 03100953  I will link it soon

@pjindal 

So products outside of OpenShift are also impacted. Any thoughts on what guidance we can provide to customers in the interim.  Are there any workarounds before the fixes arive ?

Thanks

Anand

Team

Can we provide answers to these questions in addition to my ask about workaround and fix timeline above.

- How can we determine which OpenShift versions or clusters are affected and which components in OpenShift are effected
- How is the vulnerability exploited? 

There are 3 Openshift cases so far today, and we need to provide some answers atleast to customers so we dont keep them in dark until the fixes arrive.

Team

Can we provide answers to these questions in addition to my ask about workaround and fix timeline above.

- How can we determine which OpenShift versions or clusters are affected and which components in OpenShift are effected
- How is the vulnerability exploited? 

There are 3 Openshift cases so far today, and we need to provide some answers atleast to customers so we dont keep them in dark until the fixes arrive.

Hello

several customers are asking for versions of components that are impacted (with in openshift 4 and 3) and also how work around documented in the CVE page (java system variable) can be implemented.

Please advise.

Thx

We have a couple customers over here with Confirmed Stateside support asking for a fix to this. 1 customer concerned with Satellite and the other concerned about this with EAP 7.3.8

In reply to comment #32:
> - How can we determine which OpenShift versions or clusters are affected and
> which components in OpenShift are effected

The CVE page lists the affected OpenShift components, which includes the following container images:

openshift-logging/elasticsearch6-rhel8
openshift4/ose-logging-elasticsearch6
openshift4/ose-metering-presto
openshift4/ose-metering-hive 
openshift3/ose-logging-elasticsearch5

These are part of the optional Logging and Metering add-ons:

https://docs.openshift.com/container-platform/4.8/logging/cluster-logging-deploying.html
https://docs.openshift.com/container-platform/4.8/metering/metering-installing-metering.html

All currently supported versions of OpenShift (3.11, 4.6+) that are using either of these add-ons are affected.

Affected Apache log4j2 Versions​ 2.0 <= Apache log4j <= 2.14.1  i.e. the new version of log4j-2.15.0 fix it

Hi
I have got a customer, who wanted to know,  is there any impact of this vulnerability  (CVE-2021-44228) on following products:
Quay 3.4.6 and Clair3.4.6 ?

Regards
Selim

Is setting the LOG4J_FORMAT_MSG_NO_LOOKUPS env variable in OpenShift (f.e. through oc set env), instead of specifying the log4j2.formatMsgNoLookups system property, a valid mitigation for log4j2 2.10+?

(In reply to Al from comment #56)
> Is setting the LOG4J_FORMAT_MSG_NO_LOOKUPS env variable in OpenShift (f.e.
> through oc set env), instead of specifying the log4j2.formatMsgNoLookups
> system property, a valid mitigation for log4j2 2.10+?

Yes, this is the advised method for OpenShift linked in this article from the Mitigation section on our CVE page:

https://access.redhat.com/solutions/6578421

For RHOSP13, the impacted component is Opendaylight, to verify if you are using Opendaylight in your deployment, you can use the command below to check:

$ openstack stack environment show overcloud | egrep "OS::TripleO::Services::OpenDaylightApi:|OS::TripleO::Services::OpenDaylightOvs:"
  OS::TripleO::Services::OpenDaylightApi: OS::Heat::None
  OS::TripleO::Services::OpenDaylightOvs: OS::Heat::None

If these return as OS::Heat::None like in the example above, you are not using OpenDayLight and therefore not impacted by this CVE.

More information about Opendaylight can be found here:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/red_hat_opendaylight_product_guide/introducing_opendaylight
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/red_hat_opendaylight_installation_and_configuration_guide/index

Note that this is NOT the default in RHOSP13, by default this service is not enabled and used, you would need to explicitly enable it using the steps documented in the links above.

In reply to comment #55:
> Hi
> I have got a customer, who wanted to know,  is there any impact of this
> vulnerability  (CVE-2021-44228) on following products:
> Quay 3.4.6 and Clair3.4.6 ?
> 
> Regards
> Selim

Quay and Clair are not affected. Quay uses log4js, which is close name-wise but is not related to the log4j project.

Red Hat Virtualization ships rhvm-appliance which includes a vulnerable version of log4j released by Red Hat EAP. Once EAP releases a fixed version of the package Red Hat Virtualization users can consume the fix with a regular update via the package manager inside the rhvm-appliance.

Red Hat Satellite bundles log4j-over-slf4j with Candlepin, however, product is not affected as it use logback framework for logging (instead of log4j-core).

Marking Red Hat Build of Quarkus as not affected, the product neither ships nor uses log4j 2.x and instead relies on Jboss Logging, furthermore log4j is excluded from the quarkus BOM.

Marking Red Hat AMQ Broker 7 as not being not affected by this flaw, the product neither ships nor uses log4j 2.x

Marking Red Hat Decision Manager (RHDM) 7 as not being not affected by this flaw, the product neither ships nor uses log4j 2.x.

Marking Red Hat EAP-XP 3 as not affected; the product does not directly ship log4j, but consumes artifacts from base EAP.

Large customer ticket volume for fixes in rhel-6/7, i created a tracker for both, let engg take a decision and not us.

This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 3.11

Via RHSA-2021:5094 https://access.redhat.com/errata/RHSA-2021:5094

This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.8

Via RHSA-2021:5108 https://access.redhat.com/errata/RHSA-2021:5108

This issue has been addressed in the following products:

  Vert.x 4.1.5 SP1

Via RHSA-2021:5093 https://access.redhat.com/errata/RHSA-2021:5093

This issue has been addressed in the following products:

  Red Hat Integration

Via RHSA-2021:5126 https://access.redhat.com/errata/RHSA-2021:5126

Are we still waiting on a release for  EAP 7.3.8 ?

This issue has been addressed in the following products:

  OpenShift Logging 5.3

Via RHSA-2021:5129 https://access.redhat.com/errata/RHSA-2021:5129

This issue has been addressed in the following products:

  Red Hat Integration

Via RHSA-2021:5130 https://access.redhat.com/errata/RHSA-2021:5130

This issue has been addressed in the following products:

  OpenShift Logging 5.1

Via RHSA-2021:5128 https://access.redhat.com/errata/RHSA-2021:5128

This issue has been addressed in the following products:

  OpenShift Logging 5.2

Via RHSA-2021:5127 https://access.redhat.com/errata/RHSA-2021:5127

This issue has been addressed in the following products:

  Red Hat Data Grid 8.2.2

Via RHSA-2021:5132 https://access.redhat.com/errata/RHSA-2021:5132

This issue has been addressed in the following products:

  Red Hat AMQ Streams 1.6.5

Via RHSA-2021:5133 https://access.redhat.com/errata/RHSA-2021:5133

This issue has been addressed in the following products:

  Red Hat Fuse 7.10

Via RHSA-2021:5134 https://access.redhat.com/errata/RHSA-2021:5134

This issue has been addressed in the following products:

  OpenShift Logging 5.0

Via RHSA-2021:5137 https://access.redhat.com/errata/RHSA-2021:5137

This issue has been addressed in the following products:

  Red Hat AMQ Streams 1.8.4

Via RHSA-2021:5138 https://access.redhat.com/errata/RHSA-2021:5138

This issue has been addressed in the following products:

  EAP 7.4 log4j async

Via RHSA-2021:5140 https://access.redhat.com/errata/RHSA-2021:5140

Is Red Hat working on a fix for Red Hat OpenShift Contains Platform 4.9? When can that be released?

This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.8

Via RHSA-2021:5148 https://access.redhat.com/errata/RHSA-2021:5148

This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.6

Via RHSA-2021:5106 https://access.redhat.com/errata/RHSA-2021:5106

This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.6

Via RHSA-2021:5141 https://access.redhat.com/errata/RHSA-2021:5141

This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.7

Via RHSA-2021:5107 https://access.redhat.com/errata/RHSA-2021:5107

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2021-44228

Hello Team,

There are multiple queries are coming from the CU, Can you please guide me for the same?

1. CU is having a cluster with 4.8.17 and using openshift-logging, so he needs to update the entire cluster with 4.8.24 or only openshift-logging? Can you please guide the channel from where he can get updates for 4.8.24? 

2. As we know that our core component has an insight operator which is used by telemetry. In that case, does only the logging operator needs to update, or is entire cluster upgrades required?

Question 1: Is this really a mandatory requirement to upgrade the cluster to 4.8.24?

Question 2: If yes, where is this documented. (Remark: If Verbund has to upgrade during system lock-down, they need to have formal proof from the vendor that this is a mandatory requirement!)

 Logging has been upgraded to 5.2.4-17 on the 14th Dec. 

Question 3: Please confirm that if openshift-logging operator upgrade is a sufficient upgrade to fix the log4j-issue?

Question 4: ACS still shows vulnerabilities on logging. Why?


   - What documentation has these details listed about the fixes? as our RHSA documentation [0]:  https://access.redhat.com/errata/RHSA-2021:5127
     say the SA is for 5.2.4, but does not specify what exact version under 5.2.4
     as when I personally install the operator, I see 5.2.4-17 as the version.

   - What is the difference between a "stable" channel in Elasticsearch Operator
     which CU sees and has 5.2.2-21 version and "stable-5.2" channel and what he needs to subscribe to have the patches for CVEs.

This issue has been addressed in the following products:

  RHPAM 7.11.1

Via RHSA-2022:0082 https://access.redhat.com/errata/RHSA-2022:0082

This issue has been addressed in the following products:

  Red Hat Fuse 7.8.2
  7.9.1
  7.10.1

Via RHSA-2022:0203 https://access.redhat.com/errata/RHSA-2022:0203

This issue has been addressed in the following products:

  RHPAM 7.12.0

Via RHSA-2022:0296 https://access.redhat.com/errata/RHSA-2022:0296

(In reply to Stoyan Nikolov from comment #67)
> Red Hat Virtualization ships rhvm-appliance which includes a vulnerable
> version of log4j released by Red Hat EAP. Once EAP releases a fixed version
> of the package Red Hat Virtualization users can consume the fix with a
> regular update via the package manager inside the rhvm-appliance.


We are running: rhvm-4.4.9.5-0.1.el8ev.noarch

Our question is what is the impact of removing the log4j RPM's on a Hosted Engine?

We have these log4j RPMs installed:
# rpm -qa | grep log4j
log4j12-1.2.17-22.module+el8+2598+06babf2e.noarch
ovirt-engine-extension-logger-log4j-1.1.1-1.el8ev.noarch
eap7-log4j2-jboss-logmanager-1.0.0-1.Final_redhat_00001.1.el8eap.noarch
eap7-log4j-jboss-logmanager-1.2.0-1.Final_redhat_00001.1.el8eap.noarch
eap7-log4j-2.14.0-1.redhat_00002.1.el8eap.noarch

What is the impact of removing them? Specifically, can we remove the 2.14 version without impact? Is this affected by the CVE?

> We are running: rhvm-4.4.9.5-0.1.el8ev.noarch
> 
> Our question is what is the impact of removing the log4j RPM's on a Hosted
> Engine?
> 
> We have these log4j RPMs installed:
> # rpm -qa | grep log4j
> log4j12-1.2.17-22.module+el8+2598+06babf2e.noarch
> ovirt-engine-extension-logger-log4j-1.1.1-1.el8ev.noarch
> eap7-log4j2-jboss-logmanager-1.0.0-1.Final_redhat_00001.1.el8eap.noarch
> eap7-log4j-jboss-logmanager-1.2.0-1.Final_redhat_00001.1.el8eap.noarch
> eap7-log4j-2.14.0-1.redhat_00002.1.el8eap.noarch
> 
> What is the impact of removing them? Specifically, can we remove the 2.14
> version without impact? Is this affected by the CVE?

RHVM 4.4.z should not install any any log4j v2 at all. See the diagnostic steps in https://access.redhat.com/solutions/6611691 for the log4j components installed with RHVM 4.4.

Hi team,

We have a customer asking if it is possible to remove the log4j dependencies, as comment #122 suggested. 

They has updated to the last 4.4.10 version and removed log4j package, but they want to remove all eap7-logj packages.