Menu
I'm using a Databricks cluster version 7.3 LTS with Scala 2.12. This version does use Log4J.
The official docs say that it uses Log4J version 1.2.17. Does this mean I do not have this vulnerability? And if I do, can I manually patch it on the cluster or do I need to upgrade the cluster to the next LTS version?
1000
Databricks recently published a blog on Log4j 2 Vulnerability (CVE-2021-44228) Research and Assessment. Databricks does not directly use a version of Log4j known to be affected by this vulnerability within the Azure Databricks platform in a way we understand may be vulnerable.
We also use a log inspection rule to detect the vulnerability. The log inspection rule 1011241 – Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228) looks for JNDI payloads in the access logs, with the default path being /var/log/*/access.
Navigate into the "META-INF" sub-directory and open the file "MANIFEST. MF" in a text editor. Find the line starting with "Implementation-Version", this is the Log4j version.
There is no standard way to overwrite log4j configurations on clusters with custom configurations. You must overwrite the configuration files using init scripts. Replace <custom-prop> with the property name, and <value> with the property value.
Databricks recently published a blog on Log4j 2 Vulnerability (CVE-2021-44228) Research and Assessment. Databricks does not directly use a version of Log4j known to be affected by this vulnerability within the Azure Databricks platform in a way we understand may be vulnerable.
If you are using Log4j within your cluster (for example, if you are processing user-controlled strings through Log4j), your use may be potentially vulnerable to the exploit if you have installed, and are using, an affected version or have installed services that transitively depend on an affected version.
If you have explicitly installed a version of Log4j 2 via Maven, it is listed under Libraries in the cluster UI. Scan your classpath to check for a version of Log4j 2. Start your cluster. Attach a notebook to your cluster.
This method does not identify cases where Log4j classes are shaded or included transitively. Locate all of the user installed jar files on your cluster and run a scanner to check for vulnerable Log4j 2 versions. Start your cluster.
As you wrote most Databricks clusters use 1.2.17 so it is different version and version affected by vulnerability is not used by Databricks.
Only one problem is when you install different version by yourself on the cluster. Even when you installed affected version you can mitigate the problem by setting Spark config in cluster advanced config as below:
spark.driver.extraJavaOptions "-Dlog4j2.formatMsgNoLookups=true"
spark.executor.extraJavaOptions "-Dlog4j2.formatMsgNoLookups=true"
you get complete e2e update on this here : https://databricks.com/blog/2021/12/13/log4j2-vulnerability-cve-2021-44228-research-and-assessment.html
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
