Regarding CVE-2021-45105: if you read the page on https://logging.apache.org/log4j/2.x/security.html, you will notice:
- Solved with an upgrade to log4j 2.17
- 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:
- \WorldServer\tomcat\webapps\ws\WEB-INF\lib
- \WorldServer\tomcat\webapps\ws-api\WEB-INF\lib
- \WorldServer\tomcat\webapps\ws-legacy\WEB-INF\lib
Optional: We also recommend updating the libraries in the
WAR files.
- \WorldServer\tomcat\webapps\ws.war\WEB-INF\lib\
- \WorldServer\tomcat\webapps\ws-api.war\WEB-INF\lib\
- \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.jarRemove
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:
- \WorldServer\tomcat\webapps\ws\WEB-INF\lib
- \WorldServer\tomcat\webapps\ws-api\WEB-INF\lib
- \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).
- \WorldServer\tomcat\webapps\ws.war\WEB-INF\lib\
- \WorldServer\tomcat\webapps\ws-api.war\WEB-INF\lib\
- \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.
