Skip to main content

Apache Log4j and Log4j2 vulnerabilities

Permanently deleted user
Updated

Page updates:

  • 9 February 2022: Patched StackState version released (v4.5.5). Added details of the Log4j vulnerability CVE-2022-23307. Impact on StackState.
  • 29 December 2021: Added details of the vulnerability CVE-2021-44832 (no impact on StackState or StackState Agent).
  • 22 December 2021: Patched StackState Agent version released.
  • 20 December 2021: Added details of the vulnerability CVE-2021-45105 (no impact on StackState or StackState Agent).
  • 17 December 2021: Patched StackState versions released.
  • 15 December 2021: Added details of the vulnerability CVE-2021-45046 (no further impact).
  • 13 December 2021: Added details of CVE-2021-44228 impact on StackState Agent JMX Exporter. 
  • 12 December 2021: Details of CVE-2021-44228 impact on StackState and required mitigation steps published.

Overview

A number of vulnerabilities have been identified in the Apache Log4j and  Apache Log4j 2 utilities. The potential impact of these vulnerabilities on StackState and the StackState Agent, and the required mitigation actions are described on this page.

  • January 24 2022: The vulnerability CVE-2022-23307 was announced. This impacts Apache Log4j versions 1.2.x. Affects versions of StackState prior to v4.5.5.
  • December 29 2021: The vulnerability CVE-2021-44832 was announced. This impacts Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding 2.3.2 and 2.12.4). As it is not possible for a remote attacker to change the logging configuration, there is no impact on StackState or StackState Agent from this vulnerability.
  • December 16 2021: The vulnerability CVE-2021-45105 was announced. This impacts Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3). There is no impact on StackState or StackState Agent from this vulnerability.
  • December 14 2021: The vulnerability CVE-2021-45046 was announced. This impacts Apache Log4j2 version 2.15.0. Affects unpatched versions of StackState and StackState Agent. Read the potential impact and mitigation actions below.
  • December 9 2021: The high severity vulnerability CVE-2021-44228 was announced via the project’s GitHub 317. This impacts Apache Log4j2 versions 2.0 to 2.14.1. Affects unpatched versions of StackState and StackState Agent. Read the potential impact and mitigation actions below.

StackState

Releases of StackState prior to the patched versions shipped with a version of ElasticSearch that contains a vulnerable Log4j library. Versions of StackState prior to v4.5.5 also use a version of Log4j impacted by CVE-2022-23307. This holds for all of the currently supported StackState release families (4.3.x, 4.4.x, 4.5.x) as well as the previous, unsupported StackState releases.

We do not believe that StackState or StackState's Elasticsearch can be exploited, but since they do contain a vulnerable library:

  • We recommend that all customers running a self-hosted StackState instance to upgrade to a release that does not include the vulnerable code. See the patched versions.
  • If you do not upgrade, we advise that you take the mitigation action described below to prevent any possible issues resulting from the vulnerabilities CVE-2021-44228 and CVE-2021-45046.
  • Elasticsearch is reported as not vulnerable to CVE-2021-45105.
  • Customers using StackState via our SaaS deployment option do not need to take any action.

StackState Agent

The RPM, DEB and MSI distributions of StackState Agent v2.14.0 and earlier contain a vulnerable Log4j library. This is only used when the JMX Exporter is enabled and is not included in the Docker container that runs the Agent. 

  • We recommend that all customers upgrade to StackState Agent v2.15 that does not include the vulnerable code. See the patched versions.
  • If you do not upgrade, we advise that you take the mitigation action described below to prevent any possible issues resulting from the vulnerabilities CVE-2021-44228 and CVE-2021-45046.

Mitigation

The advised mitigation route is to upgrade StackState and StackState Agent to a release that does not contain any vulnerable code. See the patched versions.

If you do not upgrade, the Log4j2 vulnerabilities can be mitigated by passing the following flag as a JVM argument in the Agent JVM check configuration and when starting Elasticsearch:

-Dlog4j2.formatMsgNoLookups=true

Instructions for applying this mitigation are described below:

Patched versions

The StackState and StackState Agent releases listed below do not contain the vulnerable code identified in the vulnerabilities CVE-2021-44228 and CVE-2021-45046. StackState v4.5.5 also removes vulnerable code identified in CVE-2022-23307.
It is advised to upgrade to use these versions:

  • StackState Agent - v2.15.0 or higher
  • StackState v4.5.x - v4.5.5 or higher - recommended.
  • StackState v4.4.x - v4.4.3
  • StackState v4.3.x - v4.3.6

StackState Agent JMX check

The advised mitigation route is to upgrade StackState Agent to a release that does not contain any vulnerable code. See the patched versions.

If you do not upgrade, the vulnerabilities CVE-2021-44228 and CVE-2021-45046 can be mitigated in the StackState Agent JMX check by adding the flag mentioned above to the init_config section of the JMX check configuration file. 

Add the following to the file conf.d/jmx.d/conf.yaml for each Agent where the JMX check is enabled.

init_config:
  java_options: -Dlog4j2.formatMsgNoLookups=true

Restart the Agent to apply changes.

Kubernetes - Elasticsearch

The advised mitigation route is to upgrade StackState to a release that does not contain any vulnerable code. See the patched versions.

If you do not upgrade, the vulnerabilities CVE-2021-44228 and CVE-2021-45046 can be mitigated in the StackState Kubernetes deployment by adding the flag mentioned above to elasticsearch.esJavaOpts in the values.yaml file that is used to deploy StackState. If you have upgraded to a patched version of StackState or use StackState via our SaaS deployment option, this mitigation step is not necessary.

If you have not overridden elasticsearch.esJavaOpts in your values.yaml file, add the following section to your values.yaml file:

elasticsearch:
    esJavaOpts: "-Xmx3g -Xms3g -Des.allow_insecure_settings=true -Dlog4j2.formatMsgNoLookups=true"
If you have overridden elasticsearch.esJavaOpts in your values.yamlfile, add -Dlog4j2.formatMsgNoLookup=true to the overriden value. For example, change
 
elasticsearch:
    esJavaOpts: "-Xmx6g -Xms6g -Des.allow_insecure_settings=true"
to:
elasticsearch:
    esJavaOpts: "-Xmx6g -Xms6g -Des.allow_insecure_settings=true -Dlog4j2.formatMsgNoLookups=true"

 

Verify that the change has been correctly applied by running this command in the namespace where the StackState instance has been deployed:

kubectl exec stackstate-elasticsearch-master-0 -c elasticsearch -- /bin/bash -c "ps -ef | grep log4j2.formatMsgNoLookups"

The output should contain the Java process for Elasticsearch, which includes the flag.

Linux - Elasticsearch

The advised mitigation route is to upgrade StackState to a release that does not contain any vulnerable code. See the patched versions.

If you do not upgrade, the vulnerabilities CVE-2021-44228 and CVE-2021-45046 can be mitigated in the StackState Linux deployment by adding the flag mentioned above to the elasticsearch section in the file etc/processmanager/processmanager.conf in the StackState installation directory and restarting StackState. If you have upgraded to a patched version of StackState or use StackState via our SaaS deployment option, this mitigation step is not necessary.

Here is an example of the processmanager.conf configuration file with the patch applied:

elasticsearch = {
name = elasticsearch
description = ""
// ES needs same heap size for Xms and Xmx, otherwise production setup checks fail
// Other settings are taken from the Elasticsearch distribution download startup scripts
commandLine = """<<java>>
  -Des.path.home=<<elasticsearch-home>>
  -Des.path.logs=<<elasticsearch-logDir>>
  -Des.path.data=<<elasticsearch-dataDir>>
  -Des.path.conf=<<elasticsearch-configDir>>
  -Des.distribution.flavor=oss
  -Des.distribution.type=tar
  -Des.bundled_jdk=false
  -Des.networkaddress.cache.ttl=60
  -Des.networkaddress.cache.negative.ttl=10
  -XX:+UseG1GC
  -XX:+ParallelRefProcEnabled
  -XX:MaxGCPauseMillis=100
  -XX:+AlwaysPreTouch
  -Xss1m
  -Dfile.encoding=UTF-8
  -Djna.nosys=true
  -Djava.awt.headless=true
  -XX:-OmitStackTraceInFastThrow
  -Dio.netty.noUnsafe=true
  -Dio.netty.noKeySetOptimization=true
  -Dio.netty.recycler.maxCapacityPerThread=0
  -Dlog4j.shutdownHookEnabled=false
  -Dlog4j2.formatMsgNoLookups=true
  -Xmx<<elasticsearch-memory>>
  -Xms<<elasticsearch-memory>>
  -XX:+ExitOnOutOfMemoryError
  -cp <<elasticsearch-classpath>>
  -Dlog4j2.disable.jmx=true
  -Djava.io.tmpdir=<<stackstateTempDir>>
  <<elasticsearch-jvm-args>>
  org.elasticsearch.bootstrap.Elasticsearch
  --quiet
  """
  statusCheckInterval = 5.second
  startupTimeout = 60.second
  withOutputLogging = true

  precheckports = [9200, 9300]
  dependencies = []
  withOutputLogging = true

  commandLineProcessController {
    specificationClass = "com.stackstate.processmanager.processcontroller.ElasticsearchProcessControllerSpecification"
    controllerClass = "com.stackvista.processmanager.processcontrollerimp.CommandLineProcessController"
  }
}

Verify that change has been correctly applied by running this command on the machine where the StackState instance has been deployed:

ps -ef | grep elastic | grep log4j2.formatMsgNoLookups

The output should contain the Java process for Elasticsearch, which includes the flag.

 

Comments

0 comments

Article is closed for comments.

Powered by Zendesk