Regarding Log4j 1.x Vulnerabilities and Possible Workarounds in Apache Ambari Environment

[#1]

Hello Cloudera Support,

We are running an environment based on Apache Ambari, where Apache Log4j 1.x is in use.
The identified security vulnerabilities are:

• CVE-2019-17571 – Insecure deserialization via SocketServer

• CVE-2020-9488 – TLS certificate hostname validation issue in SMTPAppender

• CVE-2022-23302 – Unprotected JNDI usage in JMSSink

Since Log4j 1.x has reached End of Life (EOL), no security updates are available.
Additionally, in our Ambari environment, upgrading to Log4j 2 is not supported by Cloudera, and therefore version upgrade is not an option.

Questions

1. Is there a supported workaround for Log4j 1.x similar to the official solution (cloudera-scripts-for-log4j) you provided for Log4j 2.x vulnerabilities?

2. Would manually removing the vulnerable classes (e.g., SocketServer.class, JMSSink.class, JMSAppender.class, SMTPAppender.class) from the Log4j 1.x JAR files cause any service interruptions or functional issues in Ambari or Hadoop components (HDFS, YARN, HBase, Hive, Kafka, etc.)?

3. Are these classes actively used by default in an Ambari environment, or can they be safely removed?

4. Do you have a supported approach to temporarily mitigate these vulnerabilities in an Ambari environment?

Current Situation
For Log4j 2.x vulnerabilities, the official Cloudera scripts were used to remove the affected classes.

However, since Log4j 1.x is used in the Ambari environment, we are looking for a similar workaround.

Could you please share the official and supported best approach for this case?

I would appreciate your assistance on this matter.

[#2 · Accepted solution]

Hello,

Unfortunately, there is no version of Ambari, supported by Cloudera, that has log4j1 removed or fixed as it was for log4j2. That script was made as a temp workaround while we upgraded log4j2 in our products.  

The log4j1 package is used by almost all components.  It can not be removed.  Cloudera also does not support removing any classes from the JAR as they may be used by the services as well and it has never been vetted or verified.

The proper path here is an upgrade to a current version of CDP where Log4j has been completely replaced with reload4j.

If you have any questions please contact us via one of the methods listed here:

https://www.cloudera.com/contact-sales.html

Regards,

Cloudera Support