Security Announcement dated 12/13/2021 – log4j (CVE-2021-44228)

Due to increased inquiries about the critical zero-day vulnerability in Log4j (CVE-2021-44228), we want to address this separately and in detail, as a supplement to the already published Release Warning from this morning.

We have analyzed all newly available information and reconfirm that all our products: enaio®, yuuvis® RAD and yuuvis® Momentum, respectively their components are not affected.

SLF4J and Logback

Mainly we use SLF4J and Logback as logging libraries in our products, which are not affected by this CVE gap, and not log4j.

There are currently a variety of tools on the market that can scan systems to identify potentially vulnerable components. A good summary can be found on the BSI page: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=6.

Some of our components have raised a false positive alert, as these tools often perform a blunt search for log4j and the string “JndiLookup.class”. This includes our enaio® index and search service:s

Index/search services in enaio® versions 9.00, 9.10 and 10.0 are Spring Boot based and use SLF4J and ultimately the LOG4j-TO-SLF4J libraries. They do not use LOG4J-CORE. 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, 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, as a precaution we will remove the vulnerable Log4j component through a hotfix. Thorough scans of the mentioned services running on port 8045 confirm this (e.g., https://gist.github.com/byt3bl33d3r/46661bc206d323e6770907d259e009b6.

(Last update 12/15/2021 3:00 PM)

Therefore, there is currently no known attack vector for these two services.

Log4j 1.2.x

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), Intrafind plugins, OS_WebServices, OS_DocumentViewer.

Although there is no direct threat here, we will also update in these components soon as a precautionary measure.

Elasticsearch

Elasticsearch is not directly affected by this CVE vulnerability, due to their use of Java Security Manager. More details here: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476.

Elasticsearch on JDK versions lower than 8u191, or 11.0.1 is vulnerable to an information leak via DNS that is fixed by a simple change to the JVM properties. The information leak does not allow access to data within the Elasticsearch cluster. As a precaution, Elasticsearch recommends setting the following flag:

-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).

Older enaio® versions

As a precaution, in addition to enaio® 9.0, 9.10 and 10.0, we have also tested the older enaio® versions that are no longer in maintenance. This includes enaio® 7.0, 7.10, 7.50, 8.0, 8.10 and 8.50. Under the same conditions as described above, these older versions are also not affected by the CVE gap.

3rd Party Component and Project Solutions

We recommend testing 3rd party components and project solutions as well as self-installed infrastructure that are not a part of the enaio®, yuuvis® RAD and yuuvis® Momentum core products. Simple quick tests can be performed by this power shell command:

gci ‘C:’ -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_} | select -exp Path

As before, we will keep a close eye on further development. If you have any questions, please contact the known support addresses.

 

Best regards

Your OPTIMAL SYSTEMS Team

 

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