Our products are not affected by this issue, since we use another logging-backend. Only the CMIS core of tia is affected and we will get in contact with the customers. If you have other software running, that might be exploitable, you can use the following ways to remediate the vulnerability:
1. Use a JVM with more secure defaults
When using Java 8, upgrade to Version 8u192 or above.
Since JVM 8u192 the JVM settings com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.rmi.object.trustURLCodebase are by default set to false. This fixes the vulnerability unless you override the defaults.
2. Fix it manually at servlet container level
Only apply this solution if you are sure, no other applications you depend on, running in the servlet container, make use of the vulnerable log4j feature. If you are unsure, you can safely apply solution three.
If you are using our reference servlet container tomcat, add the following line to bin/setenv.sh on Linux or bin/setenv.bat on Windows:
Linux:
| Code Block |
|---|
export JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true" |
Windows:
| Code Block |
|---|
set "JAVA_OPTS=%JAVA_OPTS% -Dlog4j2.formatMsgNoLookups=true" |
Other servlet container and application servers provide a similar way to set container settings at startup.
3. Fix it manually at application level.
Find the JndiLookup class delivered with log4j-core and delete it from the classpath.
Its location might be org/apache/logging/log4j/core/lookup/JndiLookup.class. But in most cases you have to search through the jar or war file. In question, contact the maintainer or consultant of the application.
...
To fix the vulnerability, please upgrade to the newest version of the affected KGS Product
This is the most simple and recommended way. New versions will be delivered in the following week (CW50).
...