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 20, 2021 – 2:30 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.1/apache-log4j-2.17.1-bin.zip.

    2. Extract the two files log4j-api-2.17.1.jar and log4j-core-2.17.1.jar from the zip file (subfolder apache-log4j-2.17.1-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® 10.0 Final:

  • Elasticsearch 7.9.3 (Build 202112201205)

  • indexservice-app.jar 10.0.11

  • searchservice-app.jar 10.0.11

enaio® 9.10 Final

  • elasticsearch_setup.exe 7.2.1 (Build 202112201146)

  • indexservice-app.jar 9.10.0.24

  • searchservice-app.jar 9.10.0.24

enaio® 9.00 SP1

  • elasticsearch_setup.exe Elasticsearch 6.2.4 (Build 202112201137)

  • indexservice-app.jar 9.00.0.15

  • searchservice-app.jar 9.00.0.15

enaio® 8.50 and earlier

  • no changes needed

yuuvis® RAD 7.16

  • Elasticsearch 7.9.3 (Build 202201061520)

yuuvis® RAD 6.16

  • Elasticsearch 7.2.1 (Build 202201071120)

yuuvis® Momentum

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

enaio® (all versions)

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 some of the created artifacts, 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 trigger 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.

enaio® 10.0 Final

  • Elasticsearch 7.9.3 (Build 202112201205)

  • indexservice-app.jar 10.0.11

  • searchservice-app.jar 10.0.11

enaio® 9.10 Final

  • elasticsearch_setup.exe 7.2.1 (Build 202112201146)

  • indexservice-app.jar 9.10.0.24

  • searchservice-app.jar 9.10.0.24

enaio® 9.00 SP1

  • elasticsearch_setup.exe Elasticsearch 6.2.4 (Build 202112201137)

  • indexservice-app.jar 9.00.0.15

  • searchservice-app.jar 9.00.0.15

enaio® 8.50 and earlier

  • no changes needed

In the following components we use an older log4j version (1.2.x) which is not affected by this CVE, as also described here: https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Affected versions are 2.0.1 <= log4j < 2.15.0.

These components can therefore also be detected as false positives by some tools, but only rarely: OS_AppConnector, enaio® webclient (Windows service), OSR3 (old repository manager), OS_WebServices, OS_DocumentViewer

Although there is no direct threat here regarding CVE-2021-44228, we will update OS_AppConnector and OS_DocumentViewer with Version 11.0 as a precautionary measure for any potential future vulnerabilities. OSR3 is no longer supported since Version 10.0 and has been replaced by the new enaio® repository-manager. The OS_WebServices component (SOAP interface) has already been set to deprecated and will no longer be part of the product as of enaio® version 10.10. Also with version 10.10, the old enaio® webclient backend (oswebclient) will be replaced by the new OSWEB microservice. enaio® exchange and enaio® filetrigger have already been updated.

Update dated March 20, 2023:

As previously announced, OS_AppConnector and OS_DocumentViewer will be updated. The following updates are planned:

  • A hotfix for OS_AppConnector version 11.0.

  • A full update of OS_DocumentViewer with version 11.0.

Furthermore, a hotfix will be provided for enaio® client Version 9.10, Version 10.0, Version 10.10 and Version 11.0 in which log4net 1.2.10 will be replaced by log4net 2.0.14.

Announcement regarding CVE-2022-23307

We are currently informing you about security gap CVE-2022-23307 with the rating 8.8 HIGH. The security gap pertains to Log4j 1.2.x in connection with the Apache Chainsaw. As a default, the connection between Log4j 1.2.x and the Apache Chainsaw is not active; it must be specifically configured.

This is not the case in our components. This means that our installations are not affected by this security gap.

enaio® client uses Governikus Signer, a third-party tool that is part of our client installation.  Governikus has published the following announcement:

Governikus Suite

  1. The potential vulnerability cannot be exploited with the administrative settings of the Java system properties that we communicated on Friday. We will provide a corresponding update of our security information in our portal shortly.

  2. In the default setting, the suite uses JBoss EAP for logging. According to the assessment performed by the manufacturer Red Hat, JBoss EAP is not affected by the security gap (https://access.redhat.com/security/vulnerabilities/RHSB-2021-009).  Since some of the suite’s services have implemented log4j 2 nevertheless, we will provide an update of the Governikus Suite with log4j 2 version 2.15 soon.

Governikus Service Components

Governikus Service Components are not affected by the vulnerability.

 

Although there is no direct threat, as soon as a new version of Governikus Signer is available (and also with the secured log4j 2.16, and not still vulnerable 2.15), we will publish the updated client installers for enaio® 9.10 and enaio® 10.0, out of an abundance of caution.

New versions for enaio® 9.10 und enaio® 10.0 were released on December 21, 2021, which support Governikus Boreum 10.2.0 and Governikus Signer 2.9.7.0:

enaio® 10.0 Final

  • enaio_client_ansi.msi 10.0.25

  • enaio_client_unicode.msi 10.0.20

enaio® 9.10 Final

  • enaio_client.msi 9.10.0043

 

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® RAD 7.16 LTS:

  • metrics-manager 7.6.22010 (also please use the provided jdk_x64.zip>, with the update to Java 1.8u312)

yuuvis® RAD 6.16 LTS:

  • inbox-service 6.15.1 (part of service-manager 6.16.32)

  • metrics-manager 7.622010 (also please use the provided jdk_x64.zip, with the update to Java 1.8u312)

yuuvis® RAD 5.20 LTS and earlier:

We will not release any precautionary hotfixes since these versions reached their EOL a long time ago. However, we will provide step-by-step instructions on how to perform these precautionary updates manually. This relates to the inbox-service, index-service, search-service, and status-service.

  • Download https://archive.apache.org/dist/logging/log4j/2.17.1/apache-log4j-2.17.1-bin.zip and extract the files log4j-api.2.17.1.jar and log4j-core-2.17.1.jar from it.

  • Unpack both .jar files to the log4j-api-2.17.0 and log4j-core-2.17.0 folders respectively

  • Open a command line (cmd) and switch to the folder

  • Execute
    <service-manager>\jdk\bin\jar.exe -cf0m log4j-[api|core]-2.17.0.jar META-INF\MANIFEST.MF .

    • Replace <service-manager> with the absolute path of the service-manager installation, execute once for each file

  • The newly created jars are uncompressed. This is necessary for the microservices

  • Unzip the microservices each to a folder.

  • In the folder, navigate to BOOT-INF\lib\ and delete the files log4j-api-2.*.jar and log4j-core-2.*.jar.

  • Copy the newly created uncompressed log4j-api and log4j-core jars to this location

  • Open a command line (cmd) and switch to the root folder of the unzipped microservices.

  • Execute
    <service-manager>\jdk\bin\jar.exe -cf0m <microservice-name>-app.jar META-INF\MANIFEST.MF .

    • Replace <service-manager> with the absolute path of the service-manager installation. Replace <microservice-name> with the name of the microservice, e.g., inboxservice. Execute once for each microservice.

  • Overwrite the original <microservice-name>-app.jar files with the newly created ones

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

 

Please refer to the navigation on the left-hand side for more information and earlier security announcements.