0

I need some information of log4j2 for updating our central versions of Mule CE 3.9.0 and Mule CE 3.9.5 (CE=Community Edition).

What is the best way to protect them and does downloading only jar files from Apache site https://dlcdn.apache.org/logging/log4j/2.12.3/ be useful to patch Mule CE 3.9?

Regards

aled
  • 21,330
  • 3
  • 27
  • 34
Vancho
  • 25
  • 7
  • Depends of your infrastructure & architecture. Do you use docker, linux, maven? Do you have a private libraries repository like nexus or artifactory? Cloud, on premise? Do you have a sysadmin team? Do you have a kind of devops? – JRichardsz Dec 27 '21 at 18:03

1 Answers1

1

As a summary you only need to find the vulnerable jars in the mule-server and in the mule flows deployed in the apps folder.

A Java project is a set of java class and libraries with complex dependencies relationship, but easy to replace one of them (manually or automated with maven), so no matter how or where log4j is being used, we just need replace the jar file.

mule community server 3.9.0

In this version, with this command find . -type f -iname "*log4j*" we will get the log4j jars:

logj4 used in mule

As we can see, the version prior to the 2.14.x

log4j-jul-2.8.2.jar
log4j-jcl-2.8.2.jar
log4j-slf4j-impl-2.8.2.jar
log4j-core-2.8.2.jar
log4j-api-2.8.2.jar
log4j-1.2-api-2.8.2.jar

But according to the official maven repository, this version is affected too :(

log4j 2.8.2

Just the 2.17.0 is safe to use

log4j 2.17.0

Source: https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core

If this change breaks your mule, just delete the specific vulnerable class:

zip -q -d
log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Source: https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

mule flow or mule app

This is not the server, is the app developed by programmers, packaged as .zip and deployed to the mule apps folder in the server.

In this layer, the app can ignore completely the server configurations and has its own jar versions.

If you don't use maven (rare), you need to search and replace the jar, app by app, similar to the server with find command but in the specific app folder:

/opt/mule_server/apps/my-mule-app

If you use maven, you could find if the jar is used with the pom.xml previewer of Eclipse Ide or with command mvn dependency:tree. Check this:

https://stackoverflow.com/a/68916675/3957754

Remember: If you not use directly this jar, you need to check if mule esb server uses it.

Here some tips from manual to automated pipelines:

mule esb monolithic with manual deployment

In this case you need to fix the server and your apps.

  • for the server, backup, stop, search the jar on lib folder and replace it with the 2.17 (after vulnerability fix) and start. Test if everything is working
  • for the mule apps, the process is the same: stop the mule server, go to your mule apps and one by one, search the jar and replace it. Start the mule server and test if everything is working

git repository , maven and one mule app by server

In this case, you don't have a big server with a big mule containing a lot of mule apps/flows. You have one light server for just one mule app.

Just search the dependency in your pom with maven and replace it.

Push your changes and in the next deploy( manual or automated) your mule app will be fixed.

Also note that this approach fix the app, not the server.

git, docker

If you are using docker, the things are easy. Just search the Dockerfile (usually in a git repository). In this file there are a lot of sentences, since the java installation until the star of mule server.

Choose the exact line between the download of mule and the start of server and put a sentence which replace the jar file

Next deploy will pick you new image version and that's all.

automated flow(devops)

Here you are using maven, gi, docker and some ci server. You just need:

  • update the git repository of your mule app (maven)
  • update the git repository of your docker image
  • deploy your fix using the ci server.

With this, you will not need human access to the production servers to fix your java application ( mule)

JRichardsz
  • 14,356
  • 6
  • 59
  • 94
  • The question is about the security vulnerabilities of log4j and how to resolve in Mule CE 3.9.5. Your answer is not related to that topic. – aled Dec 27 '21 at 18:58
  • On any java application, the only way to **resolve** is remove the jar or some specific class in the jar. In mule is the same. Mule just use that library, mule is not the log4j creator. What did you expect? I manage several mule servers. That is why I share you the validated steps to **resolve** this vulnerability. – JRichardsz Dec 27 '21 at 21:06
  • On rereading the answer, the first section of your answer is related to the question. I suspect that more details are needed since there are multiple jar libraries related to Log4j2. – aled Dec 27 '21 at 21:12
  • No matter how or where log4j is being used. The vulnerability is on the 2.14.x version. If you are using maven (as I explain) it is easy to detect that version, exclude it and re build. A Java project is a set of java libraries with complex dependency relationship, but easy to replace one of them. Please help me to improve this answer to help to be helpful to the java & mule community – JRichardsz Dec 27 '21 at 21:26
  • Thanks @JRichardsz As i have installed 3.9.5 also i see there is 2.8.2 log4j files in my mule runtime , so after i replace i think i will be fine? – Vancho Dec 28 '21 at 09:15
  • According to the news, just a replace pf jar works. Note that this will fix your server, not your applications. I explained how to fix the server and the apps – JRichardsz Dec 28 '21 at 12:59
  • Mentioning the specific libraries was the right thing to do. I would change 'monolithic' by 'standalone' since the former is not a term used normally. For applications patching at the server level should be a last resource. Patching at the source project level is better even if not using maven. – aled Dec 29 '21 at 13:41