KubeSphere fixes the latest vulnerability in Apache Log4j 2 remote code execution

Apache Log4j 2 is an open source logging tool, which is widely used in various frameworks. Recently, a vulnerability in Apache Log4j 2 has been revealed, and the vulnerability has now been disclosed. This article provides recommended fixes for KubeSphere users.

This vulnerability is caused by the lookup function provided by Log4j 2, which allows developers to read the configuration in the corresponding environment through some protocols. However, in the process of implementation, no strict judgment was made on the input, which caused loopholes. As a large number of software uses the Log4j 2 plug-in, a large number of Java products have been affected, including but not limited to Apache Solr, srping-boot-strater-log4j2, Apache Struts2, ElasticSearch, Dubbo, Redis, Logstash, Kafka... For more components, please refer to Log4j 2 related documents .

The affected Log4j version is Apache Log4j 2.x <2.15.0-rc2. At present, the official release of Apache 2.15.0-rc2 version fixes the vulnerability, but this version is not an informal release, so there are unstable factors. If you want to upgrade, it is recommended to back up the relevant data.

At the same time, three methods are also provided to remedy the vulnerability.

• Set the system environment variable FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS to true
• Modify configuration log4j2.formatMsgNoLookups=True
• Modify JVM parameters -Dlog4j2.formatMsgNoLookups=true

You can choose one of the following three solutions for reference.

Method 1: Modify system environment variables

Since KubeSphere uses ElasticSearch to collect logs by default, the corresponding configuration should also be modified in KubeSphere to fix the vulnerabilities. The following explains how to perform corresponding operations in KubeSphere to repair ElasticSearch.

Set the system environment variable FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS to True. For this, we need to modify the ElasticSearch Yaml file, because it is a StatefulSet file, so we need to make the following modifications:

kubectl edit  statefulset  elasticsearch-logging-data -n kubesphere-logging-system
kubectl edit  statefulset  elasticsearch-logging-discovery  -n kubesphere-logging-system

Insert environment variable settings in these two Yaml files:

env:
- name: FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS
  value: "true"

Method 2: Modify Log4j 2 configuration

In addition, you can also modify the configuration log4j2.formatMsgNoLookups=True , you can execute the following command:

kubectl edit configmaps elasticsearch-logging  -n kubesphere-logging-system

Then insert the configuration mentioned above:

log4j2.properties: |-
    status=error
    appender.console.type=Console
    appender.console.name=console
    appender.console.layout.type=PatternLayout
    appender.console.layout.pattern=[%d{ISO8601}][%-5p][%-25c{1.}] %marker%m%n
    rootLogger.level=info
    rootLogger.appenderRef.console.ref=console
    logger.searchguard.name=com.floragunn
    logger.searchguard.level=info
    # 插入此行
    log4j2.formatMsgNoLookups=true

Notice:

1. After modification, please pay attention to whether the relevant configuration is mounted. If it is not mounted, please restart the Pod.
2. If you reinstall the KubeSphere Logging component, ks-installer may cause the configuration of the ConfigMap to be reset. You need to configure it again by referring to method two, or use method one to set the system environment variable 161c2f72a6c29a FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS to true.

Method 3: Modify the JVM parameters of ElasticSearch

In addition to the above two methods, you can also choose to add configuration files to ElasticSearch in the KubeSphere cluster and configure JVM parameters separately. For details, see ElasticSearch announcement statement .

Related references

• Risk tips on the latest vulnerabilities in Apache Log4j 2 remote code execution: https://itsc.nju.edu.cn/7a/42/c41947a555586/page.htm
• Artifacts using Apache Log4j Core：https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/usages?p=1

This article is published by the blog one article multi-posting OpenWrite