Okera Response to CVE-2021-44228

Updates

Mon Dec 20 19:36 EST 2021

Final update:
We have now released version 2.8.2 in addition to versions 2.3.10, 2.5.9, 2.6.7, and 2.7.7.  These releases upgrade log4j to version 2.16. We recommend all customers upgrade immediately.

Wed Dec 15 12:50 EST 2021

Okera is aware of the newly reported CVE-2021-45046 which impacts the mitigation efforts of the previous log4j vulnerability.

To mitigate the first vulnerability, Okera had recommended upgrading to one of our latest releases which upgrade log4j to 2.15 (2.8.1, 2.7.6, 2.6.6, 2.5.8, 2.3.9) or setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

Since then, new research has shown that these mitigations may not be complete. The latest vulnerability CVE-2021-45046 applies "when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC)".

Okera does not use Context Lookup or the ThreadContext for logging.

Okera's engineering team is working on upgrading to the latest log4j version 2.16. We will notify our customers as soon as these new releases are available.

Wed Dec 15 11:50 EST 2021

Okera is aware of the concerns regarding the followup to the log4j CVE and is performing the necessary due diligence to upgrade to log4j-2.16. We will update you shortly regarding any action you may need to take.

Problem

NIST has released the following threat alert. It is available in its entireity here: https://nvd.nist.gov/vuln/detail/CVE-2021-44228.

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

Answer

The team has been actively working on the issue since Friday. Please note that all versions 2.2.x and higher are affected.

1. We have so far been unsuccessful in our attempts to run the exploit against ODAS. This is not to say we do not have the vulnerability, only that we have not been able to exploit it.
2. In the short term, set the option  You can do this by
   1.  Editing the odas-config yaml and redeploying. Add  the following line to the config: section of the file.
      

      LOG4J_FORMAT_MSG_NO_LOOKUPS=true

   2. Or,  modify the config: section of the odas-config through the kubernetes CLI for each OKERA cluster. If you edit your live cluster (rather than perform a deployment), please be sure to apply the same change to your deployment files.
      

      kubectl -n <name space> edit configmap odas-config

3. The following releases are available in quay.io (2.7.6 is also available in dockerhub).

   • 2.8.1
   • 2.7.6
   • 2.6.6
   • 2.5.8