Security Patch - December 2021

A vulnerability has been uncovered on December 10th, 2021,  in the Apache Log4j2 library, tracked under the following reference:  CVE-2021-44228. The vulnerability has been dubbed Log4Shell exploit.
You can find here and here some pretty detailed explanation of the vulnerability, its impact and level of risk.

The versions of Log4j impacted by the vulnerability are  from 2.0-beta9 to 2.14.1. The Apache foundation released version 2.15 which is addressing the issue. 

Impacted versions

• All versions of Jahia before 8.1 are using an older version of Log4j (1.2.17), meaning that they are not impacted with this vulnerability.
• You may be at risk  if you are using the elasticsearch-connector  / elasticsearch-connector-7 modules OR if you are in the specific case where one of your custom modules is having a dependency on a specific log4j version, as some modules can embed log4j2 library.
  You can check for the presence of log4j2 libraries in the folder JAHIA_HOME/digital-factory-data/bundles-deployed by running the following command (under Linux) :

  find JAHIA_HOME/digital-factory-data/bundles-deployed -name "log4j*2"

• You may also be at risk if you are running jCustomer version 1.3 or more recent, as it comes with log4j2.
  • jCustomer 1.3 and 1.4 are using Log4j2 2.8.2
  • jCustomer 1.5 is using Log4j2 2.13.0 

Mitigations

Jahia

If you are at risk and in the following cases, then specifying -Dlog4j2.formatMsgNoLookups=true as JVM parameter will block the vulnerability:

• If you are running Jahia 8.1 or
• If you are running Jahia 7.0+ or Jahia 8.0+ with modules depending on log4j2 >=2.10+ or
• If you are using elasticsearch-connector 2.0+ or elasticsearch-connector-7 module

Edit the tomcat/bin/setenv.sh (or .bat for Windows) file on all cluster nodes and add:

export JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true $JAVA_OPTS"

 Restart your nodes.

• If you are running  Jahia 7.0+ or Jahia 8.0+ with modules depending on log4j2 <2.10

If possible, update the log4j2 version in the corresponding module to the latest one. Or at least to version 2.10+ to benefit from the the previous mitigation based on the JVM parameter.

If not possible, run the following command to remove the JndiLookup class from the classpath for all modules (.jar) providing the log4j2 library:

zip -q -d MODULE_NAME.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Redeploy these patched versions of your modules. If you are embedding dependencies (including) log4j2, you should upgrade to version 2.16.0. If you have transitive dependencies that include log4j2, make sure to add an exclusion in the pom.xml and include a more recent version of log4j2 in its place.

• If you are using elasticsearch-connector 1.1.0 (compatible with Jahia 7.3)

 This module embeds the Log4j2 2.8.2 library, and even if it's not clear if or how the vulnerability could be exploited, you shall update to elasticsearch-connector 1.1.1 which comes with Log4j2 2.16.0, fixing the vulnerability.

jCustomer

• If you are running jCustomer 1.5.x

Edit the bin/setenv file on all nodes and add:

export KARAF_OPTS="-Dlog4j2.formatMsgNoLookups=true $KARAF_OPTS"

Restart jCustomer.

• If you are running jCustomer 1.3 or 1.4

Edit the value of log4j2.pattern in the  JCUSTOMER_HOME/etc/org.ops4j.pax.logging.cfg file on all nodes with the following line:

log4j2.pattern = %d{ISO8601} | %-5p | %-16t | %-32c{1} | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m{nolookups}%n 

No restart is needed.

Elasticsearch

Elasticsearch is also impacted with this vulnerability and we advise our customers to also apply the mitigation on these environments. You can consult this announcement by Elastic to learn more.

JDK

Please also note that JDK 8u191, or more recent, and  JDK 11.0.1, or more recent, provide additional levels of mitigation to the vulnerability, but it does not fully protect you against it. The only way to completely block the vulnerability is to use the mitigations mentioned above.