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
Created on 12-19-2021 02:30 AM - edited 12-19-2021 03:37 AM
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
Created 12-20-2021 07:09 AM
I think Cloudera is using the 1.x log4j
Is there any plan to apply mitigation to the 1.x?
Created 12-22-2021 07:56 AM
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?
Created on 12-28-2021 10:07 AM - edited 12-28-2021 01:12 PM
@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.
Created on 01-13-2022 06:36 AM - edited 01-13-2022 07:37 AM
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
Created on 12-22-2021 02:07 PM - edited 12-22-2021 02:09 PM
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
Created 12-23-2021 06:06 AM
@dturner The top of the CDP Trust Center page mentions the current efforts on CVE-2021-45105 and other Log4j2 issues.
Created 01-18-2022 12:30 PM
Does the cloudera script handle the JndiLookup class for Log4j 1.x as well?
Created 01-19-2022 05:53 AM
I don't believe it does
Created 01-19-2022 11:49 AM
@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.