OEM & Open Source Offerings

Update: Dec 21, 2021

The Apache Community has identified multiple exploits in log4j v2.x, which is a logging library. At present, the community has reported the following critical- and high-severity events:

CVE-2021-44228 (Critical) Risk Type: Remote Code Execution - 12/6

CVE-2021-45046 (Critical) Risk Type: Remote Code Execution - 12/14

CVE-2021-45105 (High) Risk Type: Denial of Service - 12/18

More details can be found on the links above, as well as on Apache’s security page here.

So what does this mean for EDB?

EDB tools using log4j**

The following tools are known to be using ANY version of log4j:

• EFM
• xDB
• Migration Toolkit

*Only EFM uses log4j 2.x. *MTK makes use of log4j 1.2, and xDB uses MTK as part of its codebase.

Impact of tools using log4j 1.x

The CVE only mentions versions 2.x of the log4j library, but there were concerns that version 1.x would also be affected.

Investigations from EDB developers has concluded that the current exploits <span style="text-decoration:underline;">do not</span> affect xDB and MTK.

In order for log4j 1.x to be impacted by CVE-2021-44228 it would need to have log4j.properties using the following two parameters:

log4j.appender.jms.TopicBindingName
log4j.appender.jms.TopicConnectionFactoryBindingName

MTK does _NOT_ use these parameters, so MTK is _NOT_ impacted by this exploit. As such, xDB is not impacted either. MTK is in the process of testing an update to its packages using log4j v2.17, which will eliminate the three risks noted above.

Mitigation**

EDB's supported remediation is delivered in EFM 4.3, which is now available for download.

Alternate steps for mitigation vary based on the CVE.

1. CVE-2021-44228 can be mitigated in either of the following ways:
   1. by editing the efm.properties file to set the following option:
      1. jvm.options=-Xmx128m -Dlog4j2.formatMsgNoLookups=true
      2. Restart EFM agent on each node to ensure the change has taken effect.
      3. This should be done on all nodes running the EFM agent.
      4. NOTE: This does NOT mitigate the risk to CVE-2021-45046; both CVE-2021-44228 and CVE-2021-45046 can be mitigated in the following workaround.
      5. You can verify that the EFM is using such options by looking at the ps output line for the process in question. The output should look similar to the one below where the important piece is -Xmx128m -Dlog4j2.formatMsgNoLookups=true:
         1. # ps -ef | grep efm
         2. efm 24506 1 0 09:13 ? 00:00:03 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.302.b08-0.el8_4.x86_64/jre/bin/java -cp /usr/edb/efm-4.2/lib/EFM-4.2.jar -Xmx128m -Dlog4j2.formatMsgNoLookups=true com.enterprisedb.efm.main.ServiceCommand __int_start /etc/edb/efm-4.2/efm.properties
   2. Update to EFM 4.3.
2. CVE-2021-45046 can be mitigated in either of the following ways:
   1. by removing the JNDILookup class from the classpath:
      1. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
      2. Restart EFM agent on each node to ensure the change has taken effect.
      3. This should be done on all nodes running the EFM agent.
   2. Update to EFM 4.3.
3. CVE-2021-45105 does not have a recommendation on mitigation at this moment from EDB.
   
   1. Mitigation for this CVE is only available via remediation in EFM 4.3.

_*Note on extent of vulnerability for EFM *_

While the workaround shown above can be applied without consequences and will make the system safer, we believe the impact this exploit has on EFM is minimal.

In order to exploit this the malicious user would need to have injected the malicious message in the efm.properties file or by passing such message as an option using the efm command line tool.

For the latter, no _invalid_ information can reach the running agent to be logged (e.g. a fake cluster name or fake node name for the promote command) as those would be caught by EFM before they are sent to the agent. A reminder: only users with access to the node itself can run the efm command anyway, and they need to have root or efm user access.

For the user to be able to inject such code to through the efm.properties file, the malicious user would need to have edit privileges on that file, which is limited to the root, or if running efm as the database user (using the "no-sudo mode") then the user would need root or postgres/enterprisedb access to the node to edit that file.

In any of the cases, the malicious user would already have access to the server, which removes the "Remote" part of the exploit, and the exploit as a whole.

xDB

No mitigation is needed as the tool is not impacted by this exploit.

MTK

No mitigation is needed as the tool is not impacted by this exploit.