@TeriStevenson, I responded to a similar question that you posted on Data Platform blog. Please take a look and let us know if you have any further questions. ... View more

@TeriStevenson, @lkwinchester   In general, every potential vulnerability needs to be seen in the specific product context, whether the product exposes a specific vulnerability and thus makes it reachable. The only CVE identifier the Apache Log4j version 2.17.1 fixes compared to the 2.17.0 release is CVE-2021-44832 (see [1]). This issue referenced by the CVE identifier CVE-2021-44832 requires that a potential attacker is able to construct a malicious Log4j configuration (details also in [1]). In the default configuration of our deployment this exposure is not the case. To become theoretically exploitable, after deployment someone needs to alter the configuration directly (“with permission to modify the logging configuration file” [1]) or potentially alter it through a Man-in-the-Middle (MitM) scenario in case a configuration is loaded remotely. However, for both points to be reachable, security best practices need to be severely violated as in the first case only trusted personnel should be able to alter such configurations (such persons can typically already execute arbitrary code anyway) and in the latter case any remote loading of a configuration has to be properly protected from tampering and thus the MitM path becomes ineffective. In essence, the 2.17.0 version is already properly protecting the deployed product when compared to the 2.17.1 version as there is seemingly no valid exploitation scenario for CVE-2021-44832 exposed in our case. With that said, we understand that some of our customers have certain security requirements that require further patching. We're investigating the effort to upgrade the log4j components in Data Platform to version 2.17.1 or later in one of the future Data Platform releases. We'll update this blog post when we have more clarity in terms of expected timeline and additional details. Reference: [1] https://logging.apache.org/log4j/2.x/security.html ... View more