The Apache Community has identified a Zero Day exploit found in log4j which is a logging library. More details related to the exploit are described in CVE-2021-44228 link.

EDB tools using log4j

The following tools are known to be using log4j:

• EFM
• xDB
• Migration Toolkit

From the list of tools above, only EFM is using log4j 2.x, which is the version mentioned in the CVE from above link, while xDB and MTK (Migration Toolkit) use the older version of log4j 1.2.

The EDB development team is working on identifying the real impact of this exploit and provide the appropriate workaround and fix. This article will be updated as investigation progresses.

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 our developers concluded in that there is some impact on older versions of the library, but not to the extend of the newer 2.x version.

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.

On the other hand, xDB doesn't use log4j at all. It used java.util.logging instead.

For this reason, EDB considers that xDB and MTK are not affected by this exploit.

Mitigation

At the moment the mitigation that EDB recommends is to disable message lookups substitution on all affected tools by setting the system property "log4j2.formatMsgNoLookups" to “true”.

EFM

Mitigation for EFM is provided using the following configuration option in theefm.properties file on all nodes running the EFM agent:

jvm.options=-Xmx128m -Dlog4j2.formatMsgNoLookups=true

Then restart EFM on each node so the changes take effect.

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:

# ps -ef | grep efm
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

*Note on extend 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.