Log4j Remote Code Execution & Denial of Service mitigation

On December 10th, 2021 a CVE notification was sent related with a Remote Code Execution 0-day exploit on the Apache log4j library. This knowledge base article will go over the impacted EDB tools, explain how to mitigate the issue while we wait for updated version of the affected tools.

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

CVE-2021-44832 (Medium) Risk Type: Remote Code Execution - 12/28

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?

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

• EFM
• xDB
• Migration Toolkit

Only EFM uses log4j 2.x. MTK used to use of log4j 1.2, and started using log4j 2.17.1 since version 55.2.1. xDB uses MTK as part of its codebase.

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 has concluded that the current exploits do not 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. Starting with version 55.2.1, MTK brings an updated log4j, version 2.17.1, which eliminates the three risks noted above.

EDB's supported remediation is delivered in EFM 4.4, 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:
2. by editing the efm.properties file to set the following option:
3. jvm.options=-Xmx128m -Dlog4j2.formatMsgNoLookups=true
4. Restart EFM agent on each node to ensure the change has taken effect.
5. This should be done on all nodes running the EFM agent.
6. NOTE: This mitigates ONLY the risk to CVE-2021-44228 but not others.
7. 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:
8. # ps -ef | grep efm
9. 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
10. Update to EFM 4.3.
11. CVE-2021-45046 can be mitigated in either of the following ways:
12. by removing the JNDILookup class from the classpath:
13. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
14. Restart EFM agent on each node to ensure the change has taken effect.
15. This should be done on all nodes running the EFM agent.
16. NOTE: This mitigates ONLY the risk of CVE-2021-44228 and CVE-2021-45046.
17. Update to EFM 4.3.
18. CVE-2021-45105 does not have a recommendation on mitigation at this moment from EDB.
19. Mitigation for this CVE is only available via remediation in EFM 4.3 and later.
20. CVE-2021-44832 does not have a mitigation at this moment from EDB.
21. Mitigation for this CVE is only available via remediation in EFM 4.4.
22. NOTE: To address ALL CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 and CVE-2021-44832 our recommendation is to update to latest EFM 4.4

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.

Customers should NOT remove or replace the log4j jar files of EFM themselves. Each EFM release is only tested and validated against the log4j jar that is shipped with it.

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

Customers should NOT remove or replace the log4j jar files of XDB themselves. Each XDB release is only tested and validated against the log4j jar that is shipped with it.

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

Additionally, MTK 55.2.1 brings log4j 2.17.1, which brings the definitive fixes to all aforementioned vulnerabilities.

Customers should NOT remove or replace the log4j jar files of MTK themselves. Each MTK release is only tested and validated against the log4j jar that is shipped with it.