Last Update: 20 December 2021

Security Update

Based on our understanding from the guidance provided by the Apache Foundation and Log4J team, the following notes represent some immediate action items that should be taken to secure Broadleaf Commerce Framework implementations. Additionally, we mention actions that can be taken to further secure external services that are commonly associated with Broadleaf implementations. This information covers both monolith implementations, as well as current microservices based implementations based on the newer microservices version of the Broadleaf Commerce Framework.

We will keep this blog updated as new information becomes available. The landscape has already changed with a couple of new CVEs being discovered. At this point, the known CVEs related to this topic are:

• CVE-2021-44228 - Use of JNDI in configuration (Log4J-core 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0)
• CVE-2021-45046 - Fix to Log4J-core 2.15.0 related to Context Lookup patterns
• CVE-2021-4104 - Use of JMSAppender (Log4J 1.2)
• CVE-2021-45105 - Context Lookup configurations can result in DDoS (Log4J-core 2.0-alpha1 through 2.16.0)

The areas of interest from a Broadleaf perspective relate to: CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105. Every Broadleaf Commerce Framework implementation (monolith or microservices) is unique and may include additional components or services outside of the base or default setup based on customizations. You should review all the components or services inside and outside your Broadleaf environment for potential vulnerability, as the scope of items identified in this document cannot be considered comprehensive.

Monolith Implementations:

Broadleaf Framework Implementation

While the default configuration for recent versions of monolith uses Spring Boot with logback, it is possible (and in some cases intentional) the implementation will be customized to use Log4J. Your build dependencies should be examined for the presence of the log4j jar. If log4j is being used in your case, you should update your maven pom.xml to specify version 2.17.0 of the log4j dependency. This is the version currently known to be mitigated by Apache as described at https://logging.apache.org/log4j/2.x/security.html. You should review your build output to confirm the version is appropriately updated and subsequently update your production deployment to mitigate.

Note that versions 1.x of Log4J are identified by Apache as not being subject toCVE-2021-44228, CVE-2021-45046, and CVE-2021-45105. If you identify your Broadleaf installation to use version 1.x of Log4J, and not version 2.x, then your installation is not in scope for these three CVEs. However, Log4J 1.x is in scope for CVE-2021-4104, but that is an entirely different severity with a different attack pattern and is outside the scope of the mitigations targeted in this document.

Solr

Solr is known to be vulnerable for CVE-2021-44228, and is not vulnerable to CVE-2021-45046 according to Apache at https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228. The latest vulnerability CVE-2021-45105 is related to CVE-2021-45046 and, therefore, should be remediated by the same actions.

The recommended remediation is to specify the -Dlog4j2.formatMsgNoLookups=true system property should be sufficient according to Apache. Based on how Solr is launched in your environment, you should make sure this system property is set as part of Solr execution. Further guidance is available at https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228. Note, you can generally detect if the system property is set via the Solr dashboard for the installation under the JVM heading. The system properties added to Java are generally listed here and -Dlog4j2.formatMsgNoLookups=true should be visible as a set property.

For those monolith implementations using Spring Boot with the Broadleaf broadleaf-boot-starter-solr maven dependency for launching Solr, new versions have been released that add the system property during Solr startup:

broadleaf-boot-starter-solr 2.3.2-GA released

broadleaf-boot-starter-solr 2.2.4-GA released

broadleaf-boot-starter-solr 2.0.3-GA released

broadleaf-boot-starter-solr 1.0.5-GA released

You can safely change your broadleaf-boot-starter-solr dependency version to upgrade to the relevant release from this list. Strictly speaking, broadleaf-boot-starter-solr 1.0.x-GA references version 5.3.1 of Solr by default, and broadleaf-boot-starter-solr 2.0.x-GA references version 7.3.1 of Solr by default. Both 5.3.1 and 7.3.1 of Solr are outside of the scope of affected versions as specified by Apache at https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228. However, since these Solr versions are configurable in broadleaf-boot-starter-solr, we have updated all versions of broadleaf-boot-starter-solr to include the mitigating system property out of an abundance of caution.

Newer Microservice Implementations:

Broadleaf Framework Implementation

The microservices version of the framework does not leverage Log4J, and leverages logback instead by default. Clients should review their build dependencies for the presence of Log4J. In the unlikely event that Log4J is used, the project pom should be updated to specify the mitigated version, which is currently 2.16.0. Note that microservice project dependencies on log4j-to-slf4j and log4j-api are not vulnerable.

Solr

Solr is known to be vulnerable for CVE-2021-44228, and is not vulnerable to CVE-2021-45046 according to Apache at https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228. The latest vulnerability CVE-2021-45105 is related to CVE-2021-45046 and, therefore, should be remediated by the same actions.

The recommended remediation is to specify the log4j2.formatMsgNoLookups=true system property should be sufficient according to Apache. Since Solr in most microservices based installations is launched via a Docker container, and the image used to back the container is a modified extension of the 8.3-slim Dockerfile from Apache using a customized config setup, it is advisable to use an environment variable to drive the system property.

1. Confirm you’re building a Docker image using a custom Dockerfile that leverages “/solr-config.sh” from the Broadleaf starter.
2. In your kubernetes manifest, Helm chart, or Docker-Compose file, specify a new environment variable for the container or pod that passes in the system property:
   
   SOLR_ARGS: '-Dlog4j2.formatMsgNoLookups=true'
   
   If you are already using this environment variable, you can append this new information to what you already specify. Note, if you are using a Helm chart, review what environment variables are available and update your chart or values files accordingly to guarantee the environment variable is actually set.

Note, you can generally detect if the system property is set via the Solr dashboard for the installation under the JVM heading. The system properties added to Java are generally listed here and -Dlog4j2.formatMsgNoLookups=true should be visible as a set property.

Kafka

Kafka is currently not affected by the vulnerability according to https://blogs.apache.org/security/entry/cve-2021-44228

Zookeeper

Zookeeper is currently not affected by the vulnerability according to https://blogs.apache.org/security/entry/cve-2021-44228