Salesforce

Critical Apache Log4j Vulnerability in WorldServer- resolution for versions 11.1.0, 11.1.1. and 11.2.x

« Go Back

Information

 
Article TypeSolution Article
Scope/EnvironmentSDL WorldServer
Symptoms/Context
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 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.15.0.

This issue impacts all WorldServer 11 versions. This issue does not impact WorldServer 10 deployments.
This article provides step-by-step resolutions for versions 11.1.0. , 11.1.1. and 11.2.x.
Resolution

WorldServer versions 11.1.0. , 11.1.1. and 11.2.x, although they are using log4j 1.x, they also contain log4j 2.6.2 as a transitive dependency.

In order to mitigate this issue for log4j 2.2.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 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
Optional (recommended) is to also replace it within the war files (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\
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.

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.

On 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. version.
Root Cause
This issue impacts all WorldServer 11 versions. This issue does not impact WorldServer 10 deployments.
Reference
Attachment 2 
Attachment 3 
Attachment 4 
Attachment 5 

Powered by