Release Warning on the critical Zero Day Exploit in Log4j (CVE-2021-44228)

We will update this announcement with new details as they emerge from our analysis. Please check back periodically.

Last update: March 10, 2021 – 17:10 PM CET

Summary:

A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1.

This announcement summarizes the currently known potential impacts to all our Products (enaio®, yuuvis® RAD and yuuvis® Momentum) and related announcements for mitigations of the issue. Our teams continue to actively work on the analysis and any actions our users should perform.

A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

On December 18th it was disclosed that the fix version 2.16 was not sufficient to address this vulnerability (CVE-2021-45105). Hence, Apache released Log4j version 2.17. Please also note our security announcement below. We have updated the instructions for the manual update of Log4j accordingly.

Updates of enaio® client were released on December 21st for users of Governikus signature services. Please refer to our security announcement below for the current version information.

On December 28, 2021 Apache released Log4j Version 2.7.1. to fix vulnerability CVE-2021-44832. Our analysis have shown that our products are not affected by this vulnerability. It is caused by JDBCAppender, which is not used in any of our components and configurations. Out of an abundance of caution we have nonetheless released hotfixes for all related components and strongly recommend to update them. Please refer to the security announcement below for the current version information. We have updated the instructions for the manual update of Log4j accordingly.

Security Announcement – log4j (CVE-2021-44228)

Elasticsearch (all versions of enaio®, yuuvis® RAD, and yuuvis® Momentum)

As stated by Elasticsearch (https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476):

Supported versions of Elasticsearch (6.8.9+, 7.8+) used with recent versions of the JDK (JDK9+) are not susceptible to either remote code execution or information leakage. This is due to Elasticsearch’s usage of the Java Security Manager. Most other versions (5.6.11+, 6.4.0+ and 7.0.0+) can be protected via a simple JVM property change. The information leak vulnerability does not permit access to data within the Elasticsearch cluster. We have released Elasticsearch 7.16.1 and 6.8.21 which contain the JVM property by default and remove certain components of Log4j out of an abundance of caution. This is applicable to both CVE-2021-44228 and CVE-2021-45046.

However, we use the IntraFind linguistics plug-in for Elasticsearch in all our products. IntraFind has published the following warning (https://intrafind.com/en/apache-log4j-updates):

The IntraFind linguistics plugin runs inside the Elasticsearch infrastructure, sharing the logging framework. Since version 5.0 Elasticsearch uses log4j2. Custom Java Security Manager configurations necessary for the plugin aggravate the vulnerability. To protect your Elasticsearch installation, please either replace the log4j jars with the current version, or add the respective option to disable the log4j feature.

Although it is not completely clear if there is an actual and confirmed attack vector due to this special configuration used by IntraFind, we trust their assessment and therefore advise to undertake the following mitigation steps to completely secure Elasticsearch installations. Since we only use IntraFind plug-ins and not the whole IntraFind product, the tools provided for this on the IntraFind web site cannot be used directly.

To perform this update manually, please follow the steps below:

  • The preferred solution to protect Elasticsearch installations, as advised by IntraFind, is to replace the log4j2 libraries with the latest version

    1. Download the file https://archive.apache.org/dist/logging/log4j/2.17.0/apache-log4j-2.17.0-bin.zip.

    2. Extract the two files log4j-api-2.17.0.jar and log4j-core-2.17.0.jar from the zip file (subfolder apache-log4j-2.17.0-bin).

    3. Stop Elasticsearch.

    4. In the <elasticsearch-install-dir>\lib folder delete the files log4j-api-2.11.1.jar and log4j-core-2.11.1.jar (or move them to some folder outside of the scope of Elasticsearch).

    5. Copy both new files to the \lib folder.

    6. In the <elasticsearch-install-dir>\bin folder, you will find the command line tool elasticsearch-sql-cli-xx.yy.zz.jar (depending on the exact Elasticsearch version). It contains an embedded version of log4j-2.14. It is part of the default Elasticsearch installation. This tool is not actively used and also not needed for a proper operation of an ES cluster. Which means that it can and should be deleted.

    7. Start Elasticsearch and do not forget to repeat the process on all Elasticsearch nodes.

  • Alternative solution, as advised by IntraFind: Disabling the feature in the log4j configuration. This can be done, as we already pointed out yesterday in our last release warning, by setting the following flag (also recommended by Elasticsearch as a precaution)
    -Dlog4j2.formatMsgNoLookups=true
    (e.g., for Elasticsearch 7.12 https://www.elastic.co/guide/en/elasticsearch/reference/7.12/advanced-configuration.html#set-jvm-option).

 

The steps above are needed only to protect the existing Elasticsearch installations. For new installations in all product lines, we have published new installers in which those changes have already been implemented.

enaio® (all versions)

 

yuuvis® RAD (all versions)

Except for the already described issues with Elasticsearch (see above), the rest of the components is not vulnerable to this CVE.

Update dated January 12, 2022:

Our latest analysis has shown that under certain circumstances yuuvis® metrics-manager may be affected by this vulnerability if debug is set as log level. Therefore, we advise you to update yuuvis® metrics-manager for yuuvis® RAD versions 7.16 LTS and 6.16 LTS. Please refer to the version information below for the current version number, which we updated on January 12, 2022.

All of our core services that are running in Service Manager are based on Spring Boot. There we use SLF4J, LOG4J-TO-SLF4J and Logback libraries, which are not vulnerable to this CVE, and not LOG4J-CORE which is affected. The statement and details from the Spring Boot developers can be found here: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

However, the log4j-core is indirectly included in the created artifacts in some of the older yuuvis® RAD versions, as a transient dependency of the Elasticsearch Client SDK, although it is neither initialized nor used in our logging mechanisms. Nevertheless, this .jar is detected by scans and triggers an alert.

Although this is a false positive, out of an abundance of caution we have removed these unused components of log4j through a hotfix.

yuuvis® Momentum (all versions)

Except for the already described issues with Elasticsearch (see above), the rest of the components is not vulnerable to this CVE, since we do not use any variant of log4j in this product.

The updated Docker image for Elasticsearch is available in our repository with the tag docker.yuuvis.org/yuuvis/elasticsearch:2022-01-11, as mentioned above.

Please install this update in your clusters if you are hosting yuuvis® Momentum yourself. Our managed yuuvis® Ultimate solution already includes this change.

 

Best regards

Your OPTIMAL SYSTEMS Team