Security Advisory 17th Dec 2021
Update: January 13th, 2022
Please see our newest security advisory for a full update on this issue.
Update: December 24th, 2021
We have updated the Apache Spark JDBC driver used by Matillion ETL for Delta Lake on Databricks customers as advised by Databricks. This update is now available for customers as version 1.59.9.
Our analysis reveals that all log4j dependencies are v2.17, except one; there is a potential vulnerability on a version of sb_slf4j-log4j being reported.
We are working with Databricks to ascertain any necessary steps for remediation, and are still awaiting an update as of 24th Dec 2021.
Matillion completed our analysis of the Apache Log4j vulnerability CVE-2021-44228 and CVE-2021-45046 announced on December 9th, 2021. Since the initial announcement, in addition to monitoring the threat, our Security and Engineering teams have been working diligently to understand the scope and risk profile of this vulnerability and fix any impacted systems. The current status and progress on the incident may be tracked on our documentation site here.
Matillion ETL on AWS, GCP, and Azure (Including Snowflake, Redshift, BigQuery, and Synapse but excluding Databricks)
We have validated all versions of the product from 1.28 to 1.59 available in AWS, GCP, and Azure and confirmed that none of the included third-party dependencies make use of the vulnerable log4j library (Ver 2.0.1-2.15.0) by default.
Matillion ETL for Databricks (on AWS and Azure)
We have identified that the Apache Spark JDBC driver used by Matillion ETL for Delta Lake on Databricks customers could be vulnerable to this issue if customers have specifically configured driver logging. Please note the default is for logging to be disabled. We are working with Databricks to ascertain any necessary steps for remediation, and are still awaiting an update on 17 Dec 2021.
Custom upgrades or configurations/AWS Private Image Build
We are aware that some customers may have made changes to their METL instances since provision. Where this is the case we are unable to offer conclusive guidance that your instance remains free from affected versions of log4j (Ver 2.0.1-2.15.0) . Where custom changes to a build have been made internally, for example Private Image Build, we recommend that you contact customer support or your internal security team for further guidance.
Please note custom jdbc drivers uploaded into Matillion ETL could include the log4j vulnerability. We recommend checking with the vendors of those drivers. You can view your custom drivers here.
For up to date information on this security advisory, please read this tech note.
For further assistance, submit a case at the Matillion Support Portal.
Frequently Asked Questions
Q: I’ve scanned my system and I see an affected library is present in the file "spark-jdbc-188.8.131.520.jar". Is this a problem?
Answer: This file is present in all Matillion builds after 1.50 but is only available for Matillion ETL for Databricks Delta lake. It is not in the executable codepath for our other products. This is due to the way we build our images. Whilst this file is present on Databricks, it is not by default vulnerable as logging is turned off by default for the JDBC driver. We are waiting for a replacement driver file from Databricks and we will issue a hotfix as soon as it is available.
Q: Matillion ETL ships with log4j 1.2.17; is Matillion ETL vulnerable to any of the reported CVEs for that version?
Answer: The known vulnerabilities for this version of log4j are:
Matillion ETL is not vulnerable to any of the above CVEs because it does not configure log4j in any way, and all of the above vulnerabilities require some configuration of log4j.
The JMSAppender is vulnerable to deserialization of non-trusted data. The application is only vulnerable when log4j is specifically configured to use JMSAppender, which is not the default. We do not configure this in Matillion ETL. See here for more information.
Externally exposed JSON endpoint vulnerable to executing a malicious payload. The application is only vulnerable when a JSON endpoint is configured and the apache-log4j-extra (version 1.2.x) jar is on the class path. We do not configure a JSON endpoint in Matillion ETL, and apache-log4j-extra is not on the class path. See here for more information.
SocketServer class is vulnerable to deserialization of non-trusted data which can be exploited to remotely execute arbitrary code. The application is only vulnerable when a SocketServer class is configured. We do not configure that in Matillion ETL. See here for more information.
SMTP appender vulnerable to a man-in-the-middle attack. The application is only vulnerable if an SMTP appender has been configured. We do not configure an SMTP appender in Matillion ETL. See here for more information.
Q: Why does Matillion ETL ship with log4j 1.2.17 if it does not use it?
Answer: There are lots of dependencies released with Matillion ETL that are not used directly. Dependencies like these are often called "transitive" dependencies.
For example, Matillion ETL might directly use dependency A, which in turn uses dependency B. Even though Matillion ETL doesn’t directly use dependency B, it will still be included in the release as it is required by dependency A.
The log4j 1.2.17 dependency is transitive, and is used by two of Matillion ETL’s dependencies:
- An Apache Hadoop client.
- A Databricks rest client.