Skip to main content

39 replies

Show previous replies
DCname
DCname
Silver ⭐️
December 14, 2021

So is a stand alone NiFi installation effected?

Translate
chr_heim
chr_heim
Silver ⭐️⭐️
December 17, 2021

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

Translate
ask_bill_brooks
Platinum ⭐️
ask_bill_brooks
Platinum ⭐️
December 17, 2021

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. 

 

 

Translate
Bill Brooks, Community Moderator Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button.
ask_bill_brooks
Platinum ⭐️
ask_bill_brooks
Platinum ⭐️
December 28, 2021

@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.

 

 

Translate
Bill Brooks, Community Moderator Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button.
dturner
dturner
Gold ⭐️
December 22, 2021

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

 

Translate
cjervis
Community Manager
cjervis
Community Manager
December 23, 2021

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

Translate
Keep the questions coming
    Eric_B
    Eric_B
    Silver ⭐️⭐️⭐️
    January 18, 2022

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

    Translate
    kevmac
    kevmac
    Silver ⭐️
    January 19, 2022

    I don't believe it does

    Translate
    ask_bill_brooks
    Platinum ⭐️
    ask_bill_brooks
    Platinum ⭐️
    January 19, 2022

    @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.

     

     

    Translate
    Bill Brooks, Community Moderator Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button.
    Terms & ConditionsAccessibility statement