Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Jan 25, 2022 7:47:50 AM
Dec 13, 2021 3:25:57 PM
Qlik is providing these mitigation steps as a temporary measure. A patch will be provided and linked here; customers are advised to move to the patch as soon as it is available.
Patches are available. See Vulnerability Testing - Apache Log4j, reference CVE-2021-44228 (also referred to as Log4Shell) for your release and the relevant patch.
Upgrade at the earliest.
@echo off
REM attunity endpoints server configuration/run script
FOR %%A IN ("%~dp0..") DO SET AT_PROD=%%~fA
REM list plugins here
SET AT_PLUGIN_LIST=-plugins rependsrv
REM set data directory based on the name of this script
SET AT_DATA_SUFFIX=
FOR /F "tokens=2 delims=_" %%A IN ("%~n0") DO SET AT_DATA_SUFFIX=%%A
IF "%AT_DATA_SUFFIX%" == "" (
SET AT_DATA=
) ELSE (
SET AT_DATA=-d data_%AT_DATA_SUFFIX%
)
IF EXIST "%AT_PROD%\jvm" (
SET AT_JAVA=%AT_PROD%\jvm\bin\java.exe
) ELSE IF EXIST "%AT_PROD%\..\jvm" (
SET AT_JAVA=%AT_PROD%\..\jvm\bin\java.exe
) ELSE IF "%JAVA_HOME%" == "" (
ECHO ERROR: JAVA Cannot be found
EXIT /b -1
) ELSE (
SET AT_JAVA=%JAVA_HOME%\bin\java.exe
)
SET AT_EXTERNAL=%AT_PROD%\externals
SET AT_LIB=%AT_PROD%\lib
SET AT_MAIN=com.attunity.infrastructure.server.PluginServer
REM <--------------- Fix Here ------------→
"%AT_JAVA%" -XX:+UseG1GC -Dlog4j2.formatMsgNoLookups=true -Dfile.encoding=UTF-8 %AT_JVM_OPT% -cp "%AT_EXTERNAL%"/*;"%AT_LIB%"/* %AT_MAIN% %AT_DATA% %AT_PLUGIN_LIST% %*
$ cd <installation-root>\Replicate\endpoint_srv\externals\
$ ren log4j-core-<version#>.jar ..\log4j-core-<version#>.jar-vulnerable
log4j-core-nolookup-<version#>.jar
from this page and place it in the same location as the vulnerable jar.$ sc stop AttunityReplicateServer
$ sc start AttunityReplicateServer
Note that if you have customized Replicate start scripts or if you are running multiple instances of Replicate on the same machine, you will have to repeat this process for the different environments and perform the equivalent edit on your modified start scripts.
#!/bin/bash
# attunity endpoints server configuration/run script
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )"
AT_PROD="${DIR}/.."
AT_PLUGIN_LIST="rependsrv"
if [ -d "${AT_PROD}/jvm" ]; then
AT_JAVA="${AT_PROD}/jvm/bin/java"
elif [ -d "${AT_PROD}/../jvm" ]; then
AT_JAVA="${AT_PROD}/../jvm/bin/java"
elif [ -z "$JAVA_HOME" ]; then
echo "ERROR: JAVA Cannot be found"
exit -1
else
AT_JAVA="${JAVA_HOME}/bin/java"
fi
AT_EXTERNAL="${AT_PROD}/externals"
AT_LIB="${AT_PROD}/lib"
AT_MAIN="com.attunity.infrastructure.server.PluginServer"
if [ -z "$AT_DATA" ]; then
AT_DATA="${AT_PROD}/data"
fi
AT_CP="${AT_EXTERNAL}/*:${AT_LIB}/*"
# <----------- Fix Here --------->
"${AT_JAVA}" -XX:+UseG1GC -Dlog4j2.formatMsgNoLookups=true -Dfile.encoding=UTF-8 ${AT_JVM_OPT} -cp "${AT_CP}" "${AT_MAIN}" -d "${AT_DATA}" -plugins "${AT_PLUGIN_LIST}" "${@:1}"
$ cd <installation-root>/replicate/endpoint_srv/externals
$ mv log4j-core-<version#>.jar ../log4j-core-<version#>.jar-vulnerable
log4j-core-nolookup-<version#>.jar
from this page and place it in the same location as the vulnerable jar.# service areplicate restart
Note that if you have customized Replicate start scripts or if you are running multiple instances of Replicate on the same machine, you will have to repeat this process for the different environments and perform the equivalent edit on your modified start scripts.
The client samples are intended for demonstration - if they were used to build an application, make sure the application uses the latest version of the log4j component (v2.15) or, alternatively, apply similar mitigation to the ones listed above by adding the system property.
For more information on the Log4j vulnerability, please visit the Support Updates Blog post.
Hi,
Is there now a hotfix mitigation available for Qlik Replicate or not? or should we wait for official Qlik Replicate patch? I see many messages including one that mitigation was discredited, so lost track.
Hello @frankvanderlee ,
The same doubt in another article was answered, see:
Hope this helps.
Regards,
John.
Hi,
Once downloaded, do we have to rename the log4j-core-nolookup-<version#>.jar to log4j-core-<version#>.jar?
Hello @qlik_ruwi ,
Not really. Because the jar files under this folder (default C:\Program Files\Attunity\Replicate\endpoint_srv\externals) will be loaded by Replicate Endpoint server, does not matter the exact name. However we strongly suggest to retain the similar naming rule to avoid confusion or duplicate jar files stay under the same location.
Regards,
John.
Hi @john_wang ,
we have done the mitigation steps described for Linux.
We have checked the log at "/opt/qlik/attunity/replicate/data/logs/repsrv
.log"
and the service was started up successfully.
Furthermore we have checked the new library and the path"log4j-core-nolookup-2.14.1\org\apache\logging\log4j\core\lookup" for the JndiLookup.class, which was missing and which is correct.
However we can't really see if the new "log4j-core-nolookup-2.14.1.jar" is used from application side, since it is not appearing in the repsrv.log and also no where in the GUI.
Is there a way to prove from application side that this library is used? Or the other way: is there a hint from application side that our mitigation steps worked? E.g. like a special log entry or something like that? Maybe we can somehow raise the loglevel?
Best Regards,
Andreas
Hello @AndreasFenske ,
Thank you so much for you following up and support.
The 2 log4j jar files are used by Replicate Endpoint Server. if you move the 2 jars out of the original location then the Endpoint Server cannot be startup anymore. This is a way to prove Replicate is using the library.
BTW, the JndiLookup.class is not used by Replicate. Even you enable Verbose Logging to all Replicate Server Logging components, Task logging components, Endpoint Server logging components, you cannot see the JndiLookup.class is called. However as part of the Apache jars, it's there always, and as you did, you can safely remove it from the jars.
Hope this helps.
Happy New Year!
John.
I downloaded and applied the patch for 2021.5 for both Replicate and QEM and noticed that the file log4j-core-2.16.0.jar was included. When I download the non-vulnerable jar, I did not see version 2.16. See screenshot. Which version should I use? Thanks!
Hello @KattiyaFD ,
Please allow me to explain in detail.
I downloaded and applied the patch for 2021.5 for both Replicate and QEM and noticed that the file log4j-core-2.16.0.jar was included
You are right. In the current paths releases (up to today), log4j 2.16.0 was included in the product installation kit.
When I download the non-vulnerable jar, I did not see version 2.16.
It's correct. As an early interim mitigation measure before patch available, we provided the same versions jars files but the lookup classes were removed from these jars. You can replace the jars without(before) product upgrade.
It's not recommended now unless you cannot do product patch upgrade, or the patch is not available yet.
Which version should I use?
Well, I'm guessing you are meaning "log4j version", the answer is , 2.16 is good however you know there are other vulnerabilities (not critical ones) and Apache fixed them in 2.17.1 (up to today), if you want, you may manually upgrade to 2.17.1 .
Feel free to let me know if you have any doubts, I'd love to help.
Regards,
John.
Hi @john_wang,
Thanks for the explanation. I will follow the steps to manually upgrade to 2.17.1, and let you know if come across any issue.
Thanks,
Kattiya