12-12-2021 10:31 PM
Hi Community,
We got an email from our IT Team regarding Apache Log4J Vulnerability.
Just wanted to understand if our implementation will be affected by this or not.
We are using the following library or package in our notebooks
import org.apache.log4j.Logger
Thanks
Lokesh
12-13-2021 12:06 AM
It depends.
The vulnerability in question is CVE-2021-44228.
Log4j 2.0-beta9 to 2.14.1 are vulnerable. With version 2.15.0 the issue is resolved.
So it depends on the version of Log4j you are running.
You can set 'log4j2.formatMsgNoLookups' to 'true' by addubg ‐Dlog4j2.formatMsgNoLookups=True” to the cluster startup params.
I do not know the log4j versions per databricks version.
Maybe someone from databricks can tell us which versions are impacted.
12-13-2021 01:46 AM
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:
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.
12-13-2021 02:49 AM
Thanks, Prabakar for getting back to us and for the detailed action steps that need to be followed.
Would you be able to provide an example of " user-controlled strings"
12-13-2021 02:53 AM
That can by anything tbh. F.e. you run a fat jar with an impacted log4j version.
But if you only use the logging provided by Databricks I think you are safe.
12-13-2021 02:55 AM
Thanks werners
12-13-2021 12:55 PM
Is the reason that log4j version 1.2.17 is not vulnerable, because it was not a feature (lookups) before version 2.0?
12-13-2021 11:34 PM
That is correct. The culprit (lookup feature) is not present in version 1.x
12-13-2021 03:48 AM
On most databricks distributions log4j version is 1.2.17
12-13-2021 05:05 AM
Okay I reckon we should be safe then
12-13-2021 06:19 AM
Is log4j 1.2.17 depreciated? Am I wrong?
Join a Regional User Group to connect with local Databricks users. Events will be happening in your city, and you won’t want to miss the chance to attend and share knowledge.
If there isn’t a group near you, start one and help create a community that brings people together.
Request a New Group