The Log4Shell vulnerability: How do I secure my Mendix apps?

On 10 December 2021, a new security vulnerability was found in the Apache Log4j 2 library. The vulnerability is dubbed Log4Shell. The Apache log4j library is commonly used in software worldwide, making it a popular choice for logging. 

Update 18/12/2021, yet again a new vulnerability (CVE-2021-45105) was found in the log4j library. This vulnerability is fixed in version 2.17, released this weekend. Unlike the previous two vulnerabilities, this one only has implications in terms of availability, but not in terms of integrity and confidentiality. Mendix has indicated on their status page that "Data and apps from customers who have followed our guidance so far are safe. We have measures in place to prevent availability issues on the Mendix Cloud caused by this vulnerability." Nevertheless, the risk must be mitigated by upgrading to version 2.17.

Update 15/12/2021, A new vulnerability (CVE-2021-45046) was found in the initial fix of the Log4Shell vulnerability (log4j V2.15). We strongly recommend updating to the latest version. Please check the Apache website for up-to-date information. 

The Log4Shell vulnerability has a maximum CVSS score of 10.0. What makes it so dangerous? There is not much skill needed to exploit the vulnerability. It is extremely simple to execute. The attacker can run Arbitrary Code on any vulnerable application and use this capability to perform an attack. This makes it a very dangerous vulnerability.

The vulnerability is even more dangerous because hackers actively search the web to find servers to exploit, giving it a mature exploitation rating. Techcrunch reports:

"The Computer Emergency Response Team (CERT) for New Zealand, Deutsche Telekom's CERT, and the Greynoise web monitoring service have all warned that attackers are actively looking for servers vulnerable to Log4Shell attacks."

We suggest you read this article on lunasec if you want to know more about the Log4shell vulnerability

But now comes the interesting part, what If you use Mendix? It isn't always easy to translate coding practices and security vulnerabilities to Mendix applications; should you be worried or not? 

In short, yes, you should be worried and take this seriously.

We start with the impact on the Mendix platform itself, then focus on your Mendix application and give you some guidance on what to do. 

Mendix has indicated that the Mx runtime is not affected by the Log4Shell vulnerability as they only use the Log4j API library, which is not impacted by the exploit.

Mendix made the following announcement on both their status page and Slack community:

"By default, Mendix applications are not vulnerable to this exploit.

1. The Mendix Runtime only depends on the log4j-api library, not on the log4j-core library, which contains the class that can be exploited. As stated by the developers of the library: “if you only depend on log4j-api, you are not affected by this vulnerability".

2. Not all Java versions are vulnerable to this exploit. JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 do not seem to be affected by this attack. This is because these versions set com.sun.jndi.ldap.object.trustURLCodebase to false by default. In the Mendix Cloud, apps on Mendix 7 will run on a Java version greater than 8u191 (1.8.0.191). Apps running on Mendix 8 and 9 will run on a Java version greater than 11.0.1.

We are investigating the other Platform parts and will post a more in-depth update shortly.

We're actively identifying and mitigating attempts to exploit this vulnerability on the Mendix Cloud."

The original Mendix message.

We recommend following the latest updates via the Mendix Status page: Mendix Technology B.V. Status.

It seems that the Mendix platform itself isn't impacted, but we recommend following the Mendix status page until Mendix finished its investigation.

If the Log4Shell vulnerability doesn't impact the Mendix platform, can it still affect my Mendix application? 
Even though the Mendix platform itself might not be impacted and the log4j library is not a standard library with the Mendix platform. There is still a chance that your app contains the vulnerability as the jar library can be downloaded from the Mendix App Store or added yourself. 

When you go into details, the vulnerability affects the following versions of the log4j library <= 2.14.1. Some sources indicate that there is only a vulnerability if used with JDK versions < than 6u211, 7u201, 8u191, and 11.0.1. However, this assumes that the vulnerability is only exploitable through a specific method.

For the sake of security, we recommend the following minimal threshold, either updating to the latest version of the jar that fixes the vulnerability or removing it altogether. There is no point in cutting it close.

How do I find out whether my application has this specific jar? 
There are various ways you can find out.

• You can manually look in the userlib folder of your Mendix project. For example, Mendix\AppName-BranchName\userlib\, and search for the Log4j jar file. 
• You can use the Java Libraries feature in the CLEVR Application Code Reviewer. ACR will indicate you have a critical security vulnerability based on the CVSS standard. Please read our product documentation to better understand how our Java Libraries feature helps you control security. 

I have the 'outdated' log4j jar in my app; what now?
There are various ways you can solve this issue. But first, let me emphasize that a jar file, in principle, is only dangerous if executed by the runtime. Hence, there is only an active vulnerability if a Java action in the runtime uses the log4j. Nevertheless, just remove it for the sake of security and technical debt if you don't use it. 

Are you using it? 
Most Mendix applications contain jars that are no longer used. For example, if you remove app store content, the jars aren't deleted. So you first need to assess whether your Mendix application uses the jar. In most cases, you can see in the userlib folder if a library is still used and by what module is looking at the (*.RequiredLib) files. 

A bit more work, but you can also move the jars from the userlib into another folder, start your application, check the errors for what jars are missing, and move those back. Once you fixed all errors, you added all the jars used by the application and effectively removed all the unused jars. 

My application uses the log4j jar; what now?
Your Mendix application uses the log4j library, so you need to update to the latest version of the log4j jar, where the vulnerability is fixed. Roughly there are two situations, you created the java action that uses the lib yourself, or you downloaded app store content. 

You or someone within the company created the Java action

You can download and install the latest version of the log4j jar file, remove the old one, and adjust the Java action accordingly. 

App Store content
This can be more difficult. There are three options here:

• Ideally, the app store content has a new release available where they patched the vulnerability by updating the jar. Here you must update the app store content and delete the old jar file from the userlib folder. 

Below you have two options if the app store content is not updated yet:

• If the app store content does not have an update yet, you can manually update the dependency to a newer version and fix the Java code. Please remember that it automatically overwrites any changes to existing app store content when updating it. So first duplicate the module, and then make changes. 

• If this is not the case, you can remove or delete the functionality using the log4j library by removing or hiding the module in the Mendix application using the library, so it will not start or/and cannot be exploited. 

This should be considered a temporary fix. We recommend switching back to the app store content as soon as they fix the vulnerability. This ensures maintainability and future support. 

We hope this blog helped you mitigate the risk in your Mendix application. The situation clearly shows the importance of regularly checking your app for known security vulnerabilities. We strongly recommend applying DevSecOps in low-code environments, and using our CLEVR Application Code Reviewer can make your life much easier. 

Please reach out to CLEVR if you need any help. We are thoroughly sweeping our product portfolio, but if we for some reason missed an issue, please report it to security@clevr.com.