question Re: log4j upgrade for CDH V5.1.1 in Support Questions

log4j upgrade for CDH V5.1.1

noamsh_88 — Thu, 23 Dec 2021 12:29:45 GMT

Hello,
We are using Cloudera V5.1.1 with log4j v1.2.17, without option to upgrade Cloudera to later version at this moment.

Does anyone has suggestion or solution how can we upgrade log4j component to latest version(2.16.0) on CDH V5.1.1?

Thanks

Re: log4j upgrade for CDH V5.1.1

GangWar — Mon, 27 Dec 2021 13:30:16 GMT

@noamsh_88 It’s not tested that C5.1.1 can work with upgraded log4j as this is no more under support cycle and no testing going on.

However you can give it a try but keep in mind CDH5 is not impacted with log4j vulnerability so you might have to examine first what is desired and then take action.

Re: log4j upgrade for CDH V5.1.1

noamsh_88 — Sun, 02 Jan 2022 12:26:42 GMT

Thanks @GangWar , we run patch for log4j provided at https://github.com/cloudera/cloudera-scripts-for-log4j

However, how can we verify our env is out from log4j risk? is there some java classes we should verify inside?

Per what we see:

1. log4shell-backup directory is empty

2. log4j V1 jars are not removed

e.g.

[root@host cloudera-scripts-for-log4j]# cat output_run_log4j_patcher.hVIY8n
Using tmp directory '/tmp'
Removing JNDI from jar files
Running on '/opt/cloudera'
Backing up files to '/opt/cloudera/log4shell-backup'
Completed removing JNDI from jar files
Completed removing JNDI from nar files
Removing JNDI from tar.gz files
Found an HDFS namenode on this host, removing JNDI from HDFS tar.gz files for platform='common'
Keytab file is not found or is empty: /var/run/cloudera-scm-agent/process/153-hdfs-NAMENODE/hdfs.keytab. Considering this as a non-secure cluster deployment.
Tar ball is not available in /user/tez/*. tez is not installed.
Keytab file is not found or is empty: /var/run/cloudera-scm-agent/process/153-hdfs-NAMENODE/hdfs.keytab. Considering this as a non-secure cluster deployment.
Tar ball is not available in /user/yarn/mapreduce/mr-framework/. mr is not installed.

[root@host cloudera-scripts-for-log4j]# ll /opt/cloudera/log4shell-backup
total 0

[root@host cloudera-scripts-for-log4j]# ll /opt/cloudera/parcels/CDH-5.11.0-1.cdh5.11.0.p0.34/jars/log4j*
-rwxr-xr-x 1 root root 481535 Apr 6 2017 /opt/cloudera/parcels/CDH-5.11.0-1.cdh5.11.0.p0.34/jars/log4j-1.2.16.jar
-rw-r--r-- 1 root root 489884 Apr 6 2017 /opt/cloudera/parcels/CDH-5.11.0-1.cdh5.11.0.p0.34/jars/log4j-1.2.17.jar
[root@host cloudera-scripts-for-log4j]# ll /usr/share/cmf/common_jars/log4j*
-rw-r--r-- 1 root root 481535 Apr 12 2017 /usr/share/cmf/common_jars/log4j-1.2.16.jar
-rw-r--r-- 1 root root 489884 Mar 30 2017 /usr/share/cmf/common_jars/log4j-1.2.17.jar

Thanks

Re: log4j upgrade for CDH V5.1.1

ask_bill_brooks — Mon, 03 Jan 2022 04:37:49 GMT

@noamsh_88, to recap:

You started out the thread saying that you are "using Cloudera V5.1.1 with log4j v1.2.17" and asked how you could upgrade to the latest version of log4j on CDH V5.1.1.
@GangWar replied that CDH 5.x is not and would not be tested with a later version of log4j, as CDH 5.x has reached End of Support (open that link and then expand the section labeled "Cloudera Enterprise products" underneath Current End of Support (EoS) Dates) and so if you tried it, you would be on your own.
He also wrote that CDH-5 was not impacted by the log4j vulnerability described in log4j2 CVE-2021-44228

You replied on 2 Jan that you ran the "patch for log4j provided at https://github.com/cloudera/cloudera-scripts-for-log4j" and asked:

how can we verify our env is out from log4j risk?
is there some java classes we should verify inside?

The very first sentence of the README.md file that renders in the browser automatically when one visits the URL you shared earlier for the cloudera-scripts-for-log4j reads:

This repo contains scripts and helper tools to mitigate the critical log4j vulnerability CVE-2021-44228 for Cloudera products affecting all versions of log4j between 2.0 and 2.14.1.

Emphasis added.

As @GangWar indicated, your environment, based on CDH 5.x, should not have had a version of log4j between 2.0 and 2.14.1 installed, and therefore should not have been vulnerable to the the log4j vulnerability described in log4j2 CVE-2021-44228. This is because, as you yourself pointed out in your original post on 23 Dec, you only had log4j v1.2.17 installed in your environment. log4j v1.2.17 is not a version of log4j between 2.0 and 2.14.1.

This also explains why, after you ran the script intended for systems using log4j versions between 2.0 and 2.14.1 on a system using log4j v1.2.17, the log4j V1 jars were not removed.

But since you ran the script for log4j provided at https://github.com/cloudera/cloudera-scripts-for-log4j anyway and presumably still have it handy, you could check manually for log4j .jar files in your environment in a similar manner that the script does and verify for yourself that none of those files still have the JndiLookup.class still present and thereby verify your environment is not at risk to the log4j vulnerability described in log4j2 CVE-2021-44228 (this information is also in the same README.md file on GitHub where the script you ran is being distributed from).