CVE-2021-45105/CVE-2021-44832 - Update to log4j 2.17.1 for Qlik Replicate and Qlik Enterprise Manager

[john_wang]

Qlik is providing vulnerabilities fixes in different versions of Qlik Replicate and Qlik Enterprise Manager, the information can be found in Vulnerability Testing - Apache Log4j dedicated article . The latest patch contains Log4j version 2.16 up to today.

Qlik customers, we have reviewed a third Log4j vulnerability in Log4j 2.16, CVE-2021-45105, and determined the relevant products (Replicate, Compose, QEM and GeoAnalytics) do not use the logging feature and context string defined in the CVE. Qlik considers the risks of Denial-Of-Service to be low and will address this in future patch releases.

Several security vulnerabilities were found in the Apache Log4j library in the last weeks,  include the fourth vulnerability CVE-2021-44832,The complete list is in the Apache security advisory.  Apache has just released fix 2.17.1 to addresses all the security vulnerabilities. Since the Apache Log4j 2.17.1 fix was released on December 29th, 2021, and we couldn't include it in our portfolio yet. As a mitigation process, we can replace the Apache Log4j library 2.14.1/2.16 with 2.17.1.

In this article we are explaining how a customer can switch to the latest log4j v.2.17 jars without (or before) getting a new kit which contains Log4j 2.17.1. For all of the QDI product kits we release with log4j v2.14.1 or later, it is possible to replace the log4j jars with the latest 2.x jars (in this case 2.17.1 but that might change next weeks). Specifically we're talking about the files log4j-core-2.17.1.jar and log4j-api-2.17.1.jar. 

Environment:

• Replicate 2021.11.0.165 (SR1), or up
• Replicate 2021.5.0.1272 (SR5), or up
• Replicate 7.0.0.1221 (SR5)
• Replicate 6.6.0.904 (SR6)
• Enterprise Manger 2021.11.0.198 (SR1), or up
• Enterprise Manger 2021.5.0.543   (SR5), or up
• Enterprise Manger 7.0.0.1607 (SR5)
• Enterprise Manger 6.6.0.790 (SR3)

Replace Log4j 2.14.1/2.16.x by 2.17.1 manually steps:

1. download Apache Log4j from Apache website, the direct download link is apache-log4j-2.17.1-bin.zip 

Update 6th April, 2022:     please use  apache-log4j-2.17.2-bin.zip , the other steps are same.     All the binary files can be download from https://archive.apache.org/dist/logging/log4j/

Update 30th Aug, 2022:     Replicate 2022.5 is compatible with apache-log4j-2.18.0-bin.zip .

2. Extract "log4j-core-2.17.1.jar" and "log4j-api-2.17.1.jar" from the zip to a temporary folder

3. Stop Replicate Endpoint Server and/or Replicate Server service (if you are running Replicate Endpoint Server)

4. Locate the vulnerable log4j-core-<version#>.jar file and rename/move them to a backup location or some other place outside of the lib folder

$ cd <installation-root>\Replicate\endpoint_srv\externals\

$ ren log4j-core-<version#>.jar  ..\log4j-core-<version#>.jar-vulnerable

5. Move "log4j-core-2.17.1.jar" and "log4j-api-2.17.1.jar" to the location where the vulnerable jars originally resided.

6. Startup the Replicate Server Service.

[adershb]

Hello Jon, 

We are on Replicate 2021.5.0.1272 (SR5) and Enterprise Manger 2021.5.0.543   (SR5). Do we still need to manually replace the  log4j 2.16.0 by 2.17.1. Can you please check and confirm?

Thanks, Adersh

[adershb]

Hello @john_wang 

We are on Replicate 2021.5.0.1272 (SR5) and Enterprise Manger 2021.5.0.543   (SR5). Do we still need to manually replace the  log4j 2.16.0 by 2.17.1. Can you please check and confirm?

Thanks, Adersh

[PICTConversionTeamDevs]

Hello @john_wang 

We are on replicate 6.6 and applied the fix guided by the qlik support

https://community.qlik.com/t5/Knowledge/CVE-2021-44228-Handling-the-log4j-lookups-critical-vulnerabi...

Do we have any solution to replace the log4j 2.11 with the higher version? It seems this document does not cover how to replace 2.11.1 with the higher version.

[john_wang]

Hello @adershb ,

Regarding your concern:

---

We are on Replicate 2021.5.0.1272 (SR5) and Enterprise Manger 2021.5.0.543   (SR5). Do we still need to manually replace the  log4j 2.16.0 by 2.17.1. Can you please check and confirm?

---

The Replicate/QEM SR5 contains Log4j 2.16.0. Qlik considers the risks of Denial-Of-Service to be low and will address this in future patch releases. BTW, Apache addressed all other vulnerabilities in  2.17.1, so you may continue to use log4j 2.16.0, or you may manually upgrade to 2.17.1 if necessary. In my opinion please upgrade to 2.17.1 (up to today) if possible. There is no harm and no risk to do the manual upgrading.

Let me know if you need any additional information.

Regards,

John.

[john_wang]

Hello @PICTConversionTeamDevs ,

Regarding the question:

---

We are on replicate 6.6 and applied the fix guided by the qlik support

https://community.qlik.com/t5/Knowledge/CVE-2021-44228-Handling-the-log4j-lookups-critical-vulnerabi...

Do we have any solution to replace the log4j 2.11 with the higher version? It seems this document does not cover how to replace 2.11.1 with the higher version.

---

I did add a note for Replicate 7.0/6.6 in this article:

If you running Replicate 7.0/6.6 or Enterprise Manger 7.0/6.6 , you can *NOT* replace the jars manually. Unless after applying the patch version which are scheduled for the first week(s) of Jan, 2022.

We are working on the 7.0/6.6 patch (higher versions patch were released already), it will be ready in this week.

Feel free to let me know if you need any additional assistance.

Regards,

John.

[adershb]

Hello @john_wang,

We have applied the Qlik Replicate 6.6 - Patch Release 14 (build 6.6.0.904) to our 6.6.0.593. Now we are on 6.6.0.904, which covers the vulnerability. Is it really necessary to manually replace the log4j 2.16.0 to 2.17.1 in 6.6.0.904, like we did in the case of Replicate 2021.5.0.1272 (SR5) and Enterprise Manger 2021.5.0.543   (SR5). 

Can you please check and confirm this.

Thanks, Adersh

[john_wang]

Hello Adersh, @adershb 

Thanks for your following up. Regarding to the doubt:

We have applied the Qlik Replicate 6.6 - Patch Release 14 (build 6.6.0.904) to our 6.6.0.593. Now we are on 6.6.0.904, which covers the vulnerability. Is it really necessary to manually replace the log4j 2.16.0 to 2.17.1 in 6.6.0.904, like we did in the case of Replicate 2021.5.0.1272 (SR5) and Enterprise Manger 2021.5.0.543   (SR5). 

Can you please check and confirm this.

---

There are multiple vulnerabilities in log4j and some are fixed in 2.16 (especially the critical ones), Apache also has released fix 2.17.1 to addresses all the security vulnerabilities (up to today, including  the minor ones). For Replicate, log4j 2.16 is good enough however depend on your organization demand, you may manually upgrade to 2.17.1.

In my opinion upgrading to 2.17.1 is highly recommended: 1) it's no harm and no risk to do upgrading; 2) it's an once job; 3) the steps are simple. you may do it in a planned maintenance time.

Let me know if you need any additional information.

Regards,

John.

[theglenndavid]

@john_wang Is there way to get patch Geo analytics to use 2.17.1? I have a client who won't settle for 2.16.

Regards,

Glenn

[john_wang]

Hello @theglenndavid ,

As far as I know from page #29 in article Apache Log4j reference :

GeoAnalytics Server (4.27.3 -4.19.1) are in the pipeline for a SR2 containing 2.17.1. They are planned to be released until mid February.

For the moment you have only GeoAnalytics Server - 4.19.1 - 4.27.3(February 2020 SR1 - May 2021 SR1) with log4j version 2.16.0

I updated the exact details which version will contain which log4j version in the GeoAnalytics log4j article https://community.qlik.com/t5/Knowledge/CVE-2021-44228-Handling-the-log4j-lookups-critical-vulnerabi...

I focus on QDI products. if you need additional information then we need QDA Support help (GeoAnalytics is QDA product). Feel free to let me know if you need any additional assistance.

Regards,

John.

[Tarmo]

Hi,

Even though Replicate 6.5 is out of support, would replacing the files still work fine for that version?