On December 9, 2021, a very serious vulnerability in the popular Java-based logging package Log4j was disclosed. This vulnerability allows an attacker to execute code on a remote server; a so-called Remote Code Execution (RCE). Because of the widespread use of Java and log4j this is likely one of the most serious vulnerabilities on the Internet since both Heartbleed and ShellShock.

It is CVE-2021-44228 and CVE-2021-45046 and it affects version 2 of log4j between versions 2.0-beta-9 and 2.14.1. It is not present in version 1 of log4j and is patched in version 2.16.0.
What about CVE-2021-45105 (released on December 20th, 2021)?

This issue impacts all WorldServer 11 versions. How do we address this issue in versions 11.3.x to 11.5.x?

Regarding CVE-2021-45105: if you read the page on https://logging.apache.org/log4j/2.x/security.html, you will notice:

1. Solved with an upgrade to log4j 2.17
2. Alternatively, this can be mitigated in the configuration:

• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

In WorldServer, we do not provide log configurations that include Context lookups like ${ctx:loginId} or $${ctx:loginId}. Also, it’s highly unlikely that a customer use such patterns. Nonetheless, the mitigation is to remove such patterns if you have them. 

If you would like to upgrade your log4j file to version 2.17, you can do this yourself and at your own risk by following the steps below, but using the log4j 2.17 file provided by Apache. The WorldServer development team does not expect issues, but please be aware that haven't tested the usage of log4j 2.17 in WorldServer versions 11.3. to 11.5. If there are issues, the process is easily reversible to use 2.16 and the mitigation still applies.

FYI: CVE-2021-45105 consequences would be a stackoverflow and eventually the application would crash, but no remote code execution.

WorldServer versions 11.3.x to 11.5.0 (included), although they are using log4j 1.x, they also contain log4j 2.6.2 as a transitive dependency. 

Note that according to https://logging.apache.org/log4j/2.x/security.html sections Fixed in Log4j 2.12.2 (Java 7) and Log4j 2.16.0 (Java 8) and Fixed in Log4j 2.15.0 (Java 8), only the log4j-core JAR file is impacted by this vulnerability. This is why the mitigation is based on log4j-core-2.6.2.jar and not on the log4j-api 2.6.2.jar file:



In order to mitigate this issue, there are 2 possible workarounds.

Workaround 1:

Before replacing the files, it is advisory to create a backup copy in a different location. Most of the files are common between folders – one single copy is enough.

In order to mitigate this issue for log4j 2.6.2, we need to remove the JndiLookup.class from within log4j-core-2.6.2.jar\org\apache\logging\log4j\core\lookup\
Attached to this article, you will find a jar file called log4j-core-2.6.2.zip with the class removed. You can either use it or just make a copy with it removed by yourself.

You will need it to replace the existing one in the following locations:

1. \WorldServer\tomcat\webapps\ws\WEB-INF\lib
2. \WorldServer\tomcat\webapps\ws-api\WEB-INF\lib
3. \WorldServer\tomcat\webapps\ws-legacy\WEB-INF\lib

Optional: We also recommend updating the libraries in the WAR files.

1. \WorldServer\tomcat\webapps\ws.war\WEB-INF\lib\
2. \WorldServer\tomcat\webapps\ws-api.war\WEB-INF\lib\
3. \WorldServer\tomcat\webapps\ws-legacy.war\WEB-INF\lib\

Important: If you have any customization or Hotfix that uses configuration files, you can simply move the WAR files outside of the tomcat/webapps folder. Webapps in Tomcat doesn’t require the WAR files to be there after they were initially expanded. This way you can make sure nothing gets wrongfully re-updated.

WorldServer (Idiom Service) should be restarted after this change.

Workaround 2:

In this workaround, we remove both log4j-core-2.6.2.jar and log4j-api-2.6.2.jar and replace them with the 2.16 version.

Attached to this article, you will find a zip file called jars_2.16.zip. The zip file contains these 2 jar files:

log4j-api-2.16.0.jar
log4j-core-2.16.0.jar

Remove log4j-core-2.6.2.jar and log4j-api-2.6.2.jar from these folders and replace them with the attached log4j-api-2.16.0.jar and log4j-core-2.16.0.jar in the following locations:

1. \WorldServer\tomcat\webapps\ws\WEB-INF\lib
2. \WorldServer\tomcat\webapps\ws-api\WEB-INF\lib
3. \WorldServer\tomcat\webapps\ws-legacy\WEB-INF\lib

Optional (recommended) is to also replace it within the wars (can be done with 7zip for example). 

1. \WorldServer\tomcat\webapps\ws.war\WEB-INF\lib\
2. \WorldServer\tomcat\webapps\ws-api.war\WEB-INF\lib\
3. \WorldServer\tomcat\webapps\ws-legacy.war\WEB-INF\lib\

Important: If you have any customization or Hotfix that uses configuration files, after stopping the Idiom service, you can simply move the WAR files outside of the tomcat/webapps folder. Webapps in Tomcat doesn’t require the WAR files to be there after they were initially expanded. This way you can make sure nothing gets wrongfully re-updated. 

WorldServer (Idiom Service) should be restarted after this change.

In a multi-server environment, the change and restart must be deployed on each Application Server on which WorldServer is deployed.

Note: this issue will be permanently solved in the upcoming WorldServer 11.7.2. where log4j 2.17 will be used.

Log4j2 is used in WorldServer. There is a critical remote code execution vulnerability for Apache Log4j2 v2.0 through v2.14.
This issue impacts all WorldServer 11 versions.

On the Jasper Report side, only versions 7.5 and 7.9 are affected. These versions are only present in WorldServer version 11.6.1 to 11.7.1.
There is no need to fix any vulnerability on the Jasper Report side for WorldServer versions below 11.6.x. where Jasper versions 5.x or 6.x are used.

These articles are relevant:

Critical Apache Log4j Vulnerability in WorldServer 11.x
Critical Apache Log4j Vulnerability in WorldServer 11.6.x and 11.7.x
Critical Apache Log4j Vulnerability in WorldServer- resolution for versions 11.1.0, 11.1.1. and 11.2.x
Critical Apache Log4j Vulnerability in WorldServer- resolution for versions 11.0.0. and 11.0.1
Are WorldServer 10.x versions affected by the critical Apache Log4j Vulnerability?