Dear customers,

on the occasion of the current reporting and demand:

 The software XELOS is NOT affected by the Log4J vulnerability.

Analysis / Detailed information

The XELOS application stack does NOT use Java program parts or libraries (NGINX, PHP) in the primary applications.

The secondary services mySQL and REDIS do not contain any Log4J parts in the used installation either

The Elastic-Search service contains the Log4J library, but according to current information the application is not exploitable ( see: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476 ). Furthermore, ElasticSearch is not enabled for direct communication in the default XELOS setup and is therefore not directly attackable. (However, an update of Elasticsearch is expected for 13.12. and will be installed promptly on all systems in technical operation after evaluation by us).

Other third-party applications in the general Linux stack could integrate the library, but are not vulnerable.

Update Elastic Search for onPremise Installations

Elasticsearch
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. Additional details below. We recommend checking your version and upgrade to 6.8.21.

Please change the docker-compose.yml as follows:

elastic:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.8.22

Restart the container afterwards:

docker-compose up -d elastic

Monitoring / further procedure

The XELOS software is regularly tested by third party security providers, including automated scans which automatically start after a security vulnerability such as Log4J becomes known. Currently, further information about the vulnerability becomes known on a regular basis and scans and our monitoring are run accordingly in order to be able to react promptly to any changes.

We will continue to keep an eye on the information about the current situation and will update this article as needed.

If unexpectedly a critical attack vector on XELOS installations through exploits should show up after all, you will be actively informed by us.

Best regards

Stefan Pasel