Critical vulnerability in log4j published

We take the notification of the German Federal Office for Information Security (BSI) dated 11.12.2021 regarding the announcement “Critical vulnerability in log4j published (CVE-2021-44228)” as an opportunity to inform you regarding our solutions.

A rated critical vulnerability in the widely used Java library Log4j allows attackers to execute arbitrary code. Since the vulnerability can be exploited without explicitly reloading malicious code, the German Federal Office for Information Security (BSI) subsequently upgraded the zero-day vulnerability to the highest warning level, red, last weekend.

__________________________

i-doit relies entirely on PHP and does not use Java at all. There, even after scans on our i-doit instances,
no log4j files.

__________________________

Likewise
none
Version of OTRS, Znuny LTS or Znuny uses log4j by default.
Only OTOBO installations using Elasticsearch could be affected.

In the OTOBO application network, only Elasticsearch uses Log4Shell and could therefore potentially be affected. https://otobo.de/de/otobo-und-cve-2021-44228/

According to current statements from Elasticsearch, OTOBO is basically not affected by the major security threats (remote code execution, data leaks). The key sentence here is: “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.”

In German: “Supported Elasticsearch versions (6.8.9 and newer, 7.8 and newer) deployed with current JDK versions (JDK9 and newer) are not at risk from remote code execution or data leaks.” (to Elasticsearch’s statement)

OTOBO has been using JDK 16, Elasticsearch since the first beta in version 7.14+. In manually set up instances using Elasticsearch with OpenJDK 8, limited .env data could probably be leaked.

__________________________

JDisc uses log4j version 1.2.17 up to build 5091. This is also vulnerable, but only in the config when JMSAppender is used. This is not used by the manufacturer and the build has been adjusted to version 2.15.0. https://blog.jdisc.com/2020/12/03/lldp-med-improved-discovery/

__________________________

The vulnerability, which could allow an attacker to execute arbitrary code by sending crafted log messages, has been identified as CVE-2021-44228 and is named Log4Shell. According to https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot OpenCelium users are not affected by this vulnerability.
not affected
because we use the default logging system instead of log4j.

However, if you want to update dependencies for log4j, you need to follow the next instruction:

Open build.gradle file and put implementation

'org.apache.logging.log4j:log4j-core:2.16.0'

in dependencies.

__________________________

We will be happy to support you with any update measures.

Kind regards,
the team of becon GmbH