Anaconda Culture
Mar 28, 2022
Why “Boomerang” Is Such a Common Term at Anaconda
Please note that we repositioned our products in March 2022.
In response to the reported vulnerability CVE-2021-44228 in the Apache Log4j2 Java library, Anaconda is conducting a thorough review of its products, repositories, packages, and internal systems to determine any potential impact on our services or our customers. Our findings detailed below indicate that Anaconda products and services are not affected by CVE-2021-44228. We will continue to monitor the situation and update this article with additional information.
Last updated: 2021-12-14
Anaconda Commercial Edition
The Anaconda Commercial Edition (ACE) repository infrastructure, on which we host the Anaconda Commercial Edition package set and its curated CVE database, is not affected by CVE-2021-44228.
CVE-2021-44228 does not affect Python itself, nor the core packages in the PyData stack. Currently, we have no reason to believe that it affects any other packages in our repository. We do not offer any version of Log4j as a conda package on any of our channels. An older 1.x version of Log4j is bundled in our “pyspark” packages, and are therefore not impacted by this vulnerability. We are continuing to actively analyze other packages in our repository for bundled Log4j archives, and will update this article with our findings.
Anaconda Team Edition
Anaconda Team Edition (ATE) does not directly utilize Log4j. The KeyCloak package, which ATE uses for identity management, utilizes Log4j 1.2.7. This version is not affected by this vulnerability, and is activated only in test scope—that is, not during live production operation. For this reason, we conclude that ATE is not impacted by CVE-2021-44228. More details about Keycloak’s use of Log4j can be found in this GitHub discussion.
Anaconda Enterprise 5
Anaconda Enterprise 5 (AE5) does not directly utilize Log4j. The KeyCloak package, which AE5 uses for identity management, utilizes Log4j 1.2.7. This version is not affected by this vulnerability, and is activated only in test scope—that is, not during live production operation. For this reason, we conclude that AE5 is not impacted by CVE-2021-44228. More details about Keycloak’s use of Log4j can be found in this GitHub discussion.
Anaconda Enterprise 5 with Apache Livy
Some AE5 customers take advantage of Apache Livy to connect AE5 to their internal Hadoop clusters. Livy utilizes Log4j 1.2.16, an older version of Log4j that is not affected by CVE-2021-44228. Furthermore, the default configuration of Livy avoids the use of the JNDI technology at the core of the exploit—so even a hypothetical, similar exploit would not apply to Livy. To further confirm that your installation of Livy avoids this hypothetical, locate the file
conf/log4j.properties.template
in your Livy installation and confirm the existence of the line
log4j.appender.console=org.apache.log4j.ConsoleAppender
If this line is present and unmodified, there is no concern. If this line is absent or modified, please feel free to share the full configuration with Anaconda Support, so that we can determine if those differences are material.
2021-12-14 Update: the hypothetical vulnerability discussed above has been captured in CVE-2021-4104. This CVE is still awaiting analysis; but out of an abundance of caution, follow our instructions here to ensure that you are not vulnerable.
Anaconda Enterprise 4 Repository
Anaconda Enterprise 4 Repository does not utilize Log4j, and is therefore not affected by CVE-2021-44228.
Anaconda Enterprise 4 Notebooks
Anaconda Enterprise 4 Notebooks (AEN4) does not directly utilize Log4j, and thus is not directly affected by CVE-2021-44228. However, AEN4 does support the use of an external Elasticsearch installation to enable searching across projects. According to the official Elasticsearch security announcement on the topic, versions 5 and later contain the vulnerable code, although versions 6 and 7 already contain mitigations.
Our official installation documentation utilizes much older versions of Elasticsearch—1.7.2 and 1.7.4—that are not impacted by this CVE. Furthermore, many customers do not utilize this project search functionality, and our standard recommendation is to disable it if that is the case. For this reason, we recommend the following steps to harden your AEN4 installation:
Verify the version of Elasticsearch. If you do wish to keep Elasticsearch support, verify that your installed version is not affected by the CVE. As indicated above, AEN4 utilizes versions 1.7.2-1.7.4 by default, which are not subject to this vulnerability.
Disable the use of Elasticsearch in AEN4. If you do not make heavy use of the project search capability, consider disabling it altogether.
- On the master node, edit the file /opt/wakari/wakari-server/etc/wakari/wk-server-config.json.
-
If the key SEARCH_ENABLED exists, set its value to false.
-
If not, create the key, and set its value to false.
-
- Restart the wakari-server process:
-
/etc/init.d/wakari-server restart; or
-
systemctl restart wakari-server
-
Anaconda Package-building Infrastructure
Anaconda’s package-building infrastructure does not utilize Log4j, and is therefore not affected by CVE-2021-44228.
Anaconda Repository Infrastructure
Anaconda’s repository infrastructure, on which we host packages available for download, is not affected by CVE-2021-44228. This includes repo.anaconda.com, anaconda.org, and api.anaconda.cloud, the repository from which we serve Anaconda Commercial Edition.
Anaconda-built, Anaconda-hosted Packages
CVE-2021-44228 does not affect Python itself, nor the core packages in the PyData stack. Currently, we have no reason to believe that it affects any other packages in our repository. We do not offer any version of Log4j as a conda package on any of our channels. An older 1.x version of Log4j is bundled in our “pyspark” packages, and are therefore not impacted by this vulnerability. We are continuing to actively analyze other packages in our repository for bundled Log4j archives, and will update this article with our findings.
Community-built, Anaconda-hosted Packages
In light of the severity of CVE-2021-44228, Anaconda has elected to take the additional step of working with its community partners, including conda-forge and bioconda, to help them determine if any of their packages are impacted by this vulnerability. We will update this article with any findings.
Anaconda Internal Systems
In conjunction with our review of Anaconda products and Conda packages, we have also conducted a thorough analysis of Anaconda’s internal systems. Our findings indicate that our internal systems are not affected by the Log4j vulnerability.
Anaconda Support
If you are an Anaconda customer and have additional questions related to how the Log4j vulnerability may impact you, please contact Anaconda Support. We take risk and vulnerability in open-source software very seriously at Anaconda and are currently dedicating all employee resources to investigate the impact of CVE-2021-44228. We will continuously update this article with the latest information.
2021-12-14 Update
NVD has published CVE-2021-4104 regarding JMSAppender in Log4j 1.2 as a cautionary measure during the analysis of CVE-2021-44228. This CVE is still awaiting formal analysis by NIST; and unlike 44228, there is no concrete attack yet associated with this CVE. Furthermore, it is only applicable if an application has modified the default configuration of Log4j to use the JMSAppender module.
The only Anaconda product impacted by this new, pending CVE is Anaconda Enterprise 5, and only when used in conjunction with Apache Livy with a customized Log4j configuration. Our existing instructions provided above ensure that you are protected from this CVE as well.
Anaconda is monitoring this vulnerability, and will update this article with any findings.
Related Resources
Talk to an Expert
Talk to one of our experts to find solutions for your AI journey.