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]

@Eric_B Yes. There is a link for non-customers of Cloudera in the blog article linked above. It's at the end of the paragraph beginning "What Cloudera products and versions are affected?"

[#3]

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

[#4]

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)

[#5]

So is a stand alone NiFi installation effected?

[#6]

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

[#7]

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.

[#8]

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

[#9]

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

[#10]

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

[#11]

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.