log4j2 vulnerability (CVE-2021-44228)

[#1]

Hello,

I wanted to ask if there's a page / instructions / info regarding the recent log4j2 vulnerability (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) and how it can affect Cloudera CDH setups? If it does affect, what are the recommended mitigations on it?

Thanks,

Mor

[#2]

Hello cloudera community,

Still running a cloudera express CDH 5.*

It will probably be replaced in a short time, so I don't want to get deep into sales questions...

Seems it is not possible to optain more informations without a sales subscription ....

Did anyone run the patcher script on a CDH  5.* and could share experiences?

I tried it on a db node - worked generally well, but I got a lot file not found errors like beneath...

....

Backing up to '/tmp/tmp.7tPLMJJOn3//opt/cloudera/parcels/CDH-5.3.2-1.cdh5.3.2.p0.10/share/doc/search-1.0.0+cdh5.3.2+0/examples/test-document/cars.tar.gz.backup '

Patching '/opt/cloudera/parcels/CDH-5.3.2-1.cdh5.3.2.p0.10/share/doc/search-1.0.0+cdh5.3.2+0/examples/test-documents/cars.tar.gz'

Running on '/tmp/tmp.JMPWCc5IeF'

Backing up files to '/tmp/tmp.oTHcouXKf1'
grep: /tmp/tmp.JMPWCc5IeF/**/*.jar: (... did not find file or folder ... )
Completed removing JNDI from jar files

unzip: cannot find or open /tmp/tmp.JMPWCc5IeF/**/*.nar, /tmp/tmp.JMPWCc5IeF/**/*.nar.zip or /tmp/tmp.JMPWCc5IeF/**/*.nar.ZIP.
No zipfiles found.
grep: /tmp/unzip_target/**/*.jar: (... did not find file or folder ...)
Completed removing JNDI from nar files
Recompressing
Completed removing JNDI from /opt/cloudera/parcels/CDH-5.3.2-1.cdh5.3.2.p0.10/share/doc/search-1.0.0+cdh5.3.2+0/examples/test-documents/cars.tar.gz

[#3]

Latest Cloudera Hive JDBC driver 2.6.15 contains shaded log4j2 v2.13.3 (according to pom.xml in META-INF/maven/org.apache.logging.log4j/log4j-core)

[#4]

So is a stand alone NiFi installation effected?

[#5]

Hi,

I am looking for an official solution to Log4j2 vulnerability - https://www.lunasec.io/docs/blog/log4j-zero-day/.
I could find on GIT Hub: https://github.com/cloudera/cloudera-scripts-for-log4j, but a JAR manipulation is odd to me, why not replace the JARs at all locations?

Where can I find an official solution?

Thanks in advance

Sharon

[#6]

I happen to find this: https://my.cloudera.com/knowledge/Resolution-for-TSB-2021-545---Critical-vulnerability-in-log4j2?id=... but it is pointing to the same JAR manipulation rather than fully upgrade.

[#7]

The script provided in https://github.com/cloudera/cloudera-scripts-for-log4j to delete the JndiLookup.class from log4j jar may have an issue if command zip or unzip is not installed on the cluster nodes. The script should initially check for yum list zip and unzip modules if available and abort if not found. Else it will give a finished message even though it had errors and didnt run successfully like below:

Completed removing JNDI from /opt/cloudera/parcels/CDH-7.1.6-1.cdh7.1.6.p0.10506313/share/doc/search-1.0.0.7.1.6.0/examples/test-documents/testJPEG_EXIF.jpg.tar.gz
Backing up to '/tmp/tmp.FsVTS5Rg9y//opt/cloudera/cm/lib/solr-upgrade-1.0.0.7.1.7.0-547.tar.gz.backup'
Patching '/opt/cloudera/cm/lib/solr-upgrade-1.0.0.7.1.7.0-547.tar.gz'
Running on '/tmp/tmp.Yxjh6FQYgS'
Backing up files to '/tmp/tmp.TsL7gbbmHR'
Completed removing JNDI from jar files
./cm_cdp_cdh_log4j_jndi_removal.sh: line 114: unzip: command not found
grep: /tmp/unzip_target/**/*.jar: No such file or directory
Completed removing JNDI from nar files
Recompressing
Completed removing JNDI from /opt/cloudera/cm/lib/solr-upgrade-1.0.0.7.1.7.0-547.tar.gz
INFO : Finished

[#8]

@ebeb Thank you for sharing. We have forwarded your post to the appropriate team to look into it. 

[#9]

PLEASE: while the patcher is meant to run on nodes.

On the machine hosting the Manager, running also the odbc /m ysql / oracle connector,  we see processes using log4j - at least they seem to be....

/usr/java/jdk1.7.0_67-cloudera/bin/java -cp .:lib/*:/usr/share/java/mysql-connector-java.jar:/usr/share/java/oracle-connector-java.jar -server -Dlog4j.configuration=file:/etc/cloudera-scm-server/log4j.properties -Dfile.encoding=UTF-8 -Dcmf.root.logger=INFO,LOGFILE -Dcmf.log.dir=/var/log/cloudera-scm-server -Dcmf.log.file=cloudera-scm-server.log -Dcmf.jetty.threshhold=WARN -Dcmf.schema.dir=/usr/share/cmf/schema -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Dpython.home=/usr/share/cmf/python -XX:+UseConcMarkSweepGC -XX:-CMSConcurrentMTEnabled -XX:+UseParNewGC -XX:+HeapDumpOnOutOfMemoryError -Xmx2G -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -XX:OnOutOfMemoryError=kill -9 %p com.cloudera.server.cmf.Main

Does this need a fix and how should it be done?

Another question would be:

The patcher running on CDH nodes produces a lot of not-found errors. Is this quite normal? It looks like it checks files of older versions.

Regards, Christian

[#10]

Christian,

You didn't indicate what version of CDH you're running the aforementioned script on, so other members of the community with the appropriate knowledge and inclination to offer assistance won't be able to offer an answer to your questions. 

[#11]

Hello Bill and sorry, I forgot to repeat that (had it written in a previous post in this thread)

Version is cloudera express CDH 5.4 (management service is stopped for security reasons at the moment)

Regards Christian

[#12]

I think Cloudera is using the 1.x log4j

Is there any plan to apply mitigation to the 1.x?

[#13]

There was a recent update from Apache; https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105 

"Apache Log4j2 does not always protect from infinite recursion in lookup evaluation", which seems to imply the mitigation strategy of removing references to jndilookup class will not address this.   Is this a concern for CDH6.3?  If so, will the patch script be updated to address?

[#14]

@Fawze that is why I asked @chr_heim what version he was talking about. It's a little imprecise to say "Cloudera is using the 1.x log4j", because different versions of Cloudera's distributions use different versions of the log4j library.

If you're interested in CDH 5.x, then sure, the version of the log4j library you most likely have deployed is log4j 1.x (you should confirm this for yourself) and you should confirm for yourself by consulting the appropriate documentation whether or not log4j 1.x is even affected by CVE-2021-44228 and therefore if applying Cloudera's short-term mitigation is necessary. My reading of the advisory that The Apache Security team released earlier this month addressing CVE-2021-44228 is that it affects Apache Log4j, versions 2.0 through 2.14.x. Other versions of CDH use a version of Log4j that is definitely within this affected group.

See Cloudera Response to CVE-2021-44228 for the details.

[#15]

Hi Team,

We are using Cloudera provided Impala JDBC Driver(2.6.20) and it is using LOG4J2 Core 2.13 version which is having the vulnerability. Is there any new verson of Impala JDBC driver present which is not impacted with the recent log4j issue?

If not is there an ETA when the fixed version is getting released?

Thanks 

PJ

[#16]

Apache recently posted an update to the existing log4j2 vulnerabilities already discussed here. 

From the Apache page:

"Apache Log4j2 versions 2.0-alpha1 through 2.16.0, excluding 2.12.3, did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack."

My company runs several private CDH6.3 clusters and we've already applied the original log4j2 patch from https://github.com/cloudera/cloudera-scripts-for-log4j.   Can anyone confirm if CDH products are susceptible to CVE-2021-45105?  Seems this particular vulnerability is enabled only if logging configuration uses a non-default pattern layout with a context lookup.  The mitigation strategy differs from that taken by the existing log4j2 patch from Cloudera.  

Apache log4j security vulnerabilities: https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105

[#17]

@dturner The top of the CDP Trust Center page mentions the current efforts on CVE-2021-45105 and other Log4j2 issues.

[#18]

Does the cloudera script handle the JndiLookup class for Log4j 1.x as well?

[#19]

I don't believe it does

[#20]

@kevmac you and @Eric_B can find out about the actual target Log4j library version for Cloudera's suggested remediation by consulting the blog post Cloudera Response to CVE-2021-44228. The version of the Log4j library that the aforementioned remediation script is intended for is specified in the very first paragraph, sub-headed Summary.