Hi @Lokesh Sharmaโ , Thank you for reaching out. As you are aware, there has been a 0-day discovery in Log4j2, the Java Logging library, that could result in Remote Code Execution (RCE) if an affected version of log4j (2.0 <= log4j <= 2.14.1) logs an attacker-controlled string value without proper validation. Please see more details on CVE-2021-44228.
Databricks does not directly use a version of log4j known to be affected by the vulnerability within the Databricks platform in a way we understand may be vulnerable to this CVE (e.g., to log user-controlled strings). We have investigated the transitive use of log4j and have not found any evidence of vulnerable usage so far.
However, depending on the way you are using log4j within your Databricks dataplane cluster (e.g., if you are processing user-controlled strings though 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 determine that you have done so, we advise to stop using an affected version of log4j until you upgrade to log4j version 2.15.x or reconfigure any affected service with the known temporary mitigation implemented (log4j2.formatMsgNoLookups set to true). Please restart the cluster once you have added the mitigation.
The steps to do so are:
- Edit the cluster and job with the spark conf โspark.driver.extraJavaOptionsโ and โspark.executor.extraJavaOptionsโ set to "-Dlog4j2.formatMsgNoLookups=true"
- Confirm edit to restart the cluster, or simply trigger a new job run which will use the updated java options.
- You can confirm that these settings have taken effect in the โSpark UIโ tab, under โEnvironmentโ
We are continuing to investigate whether the Databricks platform may be vulnerable to this security issue and will provide a proactive notification if we determine that you may have been impacted or need to take any further steps.
.png){kind=link}
