Issue background

Dear LAIKA users, as you may know the beginning of December 2021 brought news not only about COVID, isolation and other things like that. It was identified that library called Apache Log4j2 beloved in the world of Java applications and widely used for logging functionality contains a critical CVE-2021-44228 vulnerability.

Such issue allows to execute remote code on the target server (RCE) and was classed severe. Affecting versions 2.0-beta9 through 2.14.1 of Log4j2. Apache Log4j released a fix to this initial vulnerability in Log4j version 2.15.0. However the fix was incomplete and resulted in a potential DoS and data exfiltration vulnerability, logged as CVE-2021-45046. This new vulnerability was fixed in Log4j2 version 2.16.0. However, version 2.16.0 itself was also found vulnerable to another DoS vulnerability, leading to a new CVE-2021-45105, and the eventual release of Apache Log4j2 version 2.17.0.

As for December 20, 2021 version 2.17.0 can be considered safe and could be used to avoid all vulnerabilities mentioned above.

LAIKA components affected

Let's take a look at the LAIKA in terms of these issues.

LAIKA digital platform code wasn't affected since LAIKA is a product based on .NET and doesn't contain any Java-based code. But LAIKA is using 3rd party components that are Java-based and might be affected.

LAIKA team analyzed all Java-based 3rd party components used and created the following list:

• Redis Server: not affected. LAIKA is using open-source version of Redis Server and it doesn't contain Log4j. Official statement could be found here.
• Apache Kafka: not affected. Both Apache Kafka and Zookeeper are based on legacy Log4j version 1 and not using Log4j2. Official statement on Apache components could be found here.
• MongoDB: not affected. MongoDB server doesn't use Java. Even Java/Scala drivers are not using Log4j. Official answer could be found here.
• Grafana: not affected. Official statement is here.
• ElasticSearch / Kibana: affected. ElasticSearch server is using Log4j2, so extra steps should be performed to mitigate the risks. Official statement could be found here.

The list above is applicable for both VM-based and Kubernetes-based installations. But it makes sense to review with types of the components you're using in terms of your installations as it will be mentioned in the next section.

Steps to perform

Please perform the following steps to mitigate all the risks for your LAIKA digital platform installations:

1. First of all to mitigate the risks you have to check what types of the 3rd party components you're using in terms of your installation (Redis Server, MongoDB, ElasticSearch, Apache Kafka). In our installation guides we recommend to use OpenSource version of Redis Server and MongoDB, use official installation package of Apache Kafka with built-in Apache Zookeeper etc., but you could use some other versions, or custom packages, or custom images (especially in IaaS / Kubernetes-based installation). You also may use cloud services for these components. Please ensure that images or cloud services you using can be considered safe in terms of these issues.

2. Update your version of ElasticSearch/Kibana to the latest possible version together with JDK/JRE to the last possible version. According to the official response version 7.16.2 can be considered safe.

   2.1. In case of VM-based installation you could just execute sudo apt upgrade procedure on your DB server where ElasticSearch is installed to upgrade all packages installed to the latest version (please do not overwrite elasticsearch configuration files during upgrade since it contains parameters configured for LAIKA, just select the option N during upgrade procedure when it will be asked) and then perform sudo reboot to restart your DB server.

   2.1 In case of IaaC / Kubernetes-based installation specify the right version of the Docker image to use to be sure that ElasticSearch 7.16.2 is in place.

3. Perform the steps above for any LAIKA environment you have.

You could also download and replace the latest version of Log4j2 libraries inside your ElasticSearch installation to resolve these issues and mitigate the risks but we not recommend to do it this way since there is more chances to make a mistake (other options to resolve the issues with ElasticSearch without upgrade could be found in this article, but LAIKA team is still recommend to upgrade ElasticSearch installation).

Conclusion

LAIKA digital platform wasn't affected by this infamous Log4j2 vulnerabilities. But at the same time ElasticSearch as a 3rd party component used for search capabilities is affected and should be upgraded to the latest possible version to avoid this issue (currently it's version 7.16.2).

Luckilly it's a very simple process in case of LAIKA: for VM-based installation just upgrade all packages installed and reboot your server, for IaaC/Kubernetes based installation just ensure that you're using the right version of the Docker image.

Also remember to double-check editions and versions of 3rd party components of your installation (Redis Server, MongoDB and ApacheKafka): it's not necessary if you're installing LAIKA using our guides, but you could use something different. Also double-check all Java-based tools, applications or custom code that you're using in terms of your environment: maybe some of them affected with this issue (for example, JMeter used for performance testing or other tools that might be installed).

Security issues of such level are really important and should be fixed as soon as it possible. Remember that you're responsible for the security of your environments and your data, so please double-check everything carefully and perform all necessary steps as soon as it possible. Thousands and thousands of applications were affected by this issue and some of them might be installed as a part of your environment.