Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
We are using Talend 6.2.1 20160704_1411 version of talend running on our local servers.
As precautionary measure we need to update log4j library to avoid recent exploit named as CVE-2021-44228.
Can anyone tell me what measure can be taken to update log4j to
Log4j 2.15.0 or apply the recommended mitigations immediately ?
But are companies that develop standalone ETL batch jobs with TOS at risk? We have 50+ jobs that are built and deployed on internal file server, scheduled to execute at various times. None of those function as web servers. We don't have Talend running as a service, either. It just functions as a Studio. Is there anything that the attacker could exploit? If they first get access to our internal network, that is. Is it really necessary to re-build all those jobs with the proposed mitigation JVM argument?
Hello,
So far, there is no any update for this issue.
With your subscription solution and securities level in your company, could you please contact our support team for an urgent patch with priority?
Best regards
Sabrina
Hello,
As there are some personal account and company information, you are not able to access support cases directly, which is an internal access for some groups of talend employees.
We will keep you update to this issue.
Best regards
Sabrina
Hello,
Sorry for the inconvenience and thank you so much for your understanding.
Our team is currently in the process of identifying all modules in Talend affected and working on a fix for the issue at hand.
We will keep you update to this issue.
Best regards
Sabrina
Hello,
I haven't received an interim solution for the runtime server from our developer team and support team yet.
We will come back to you as long as there is any update for this.
Best regards
Sabrina
Hi all,
We're using Talend Open Studio 7.1 in order to develop standalone ETL batch jobs. All of them have been deployed on an internal server and have been scheduled to be executed at various times. As we can see, this version uses the old 1.X libraries of log4j, so do we need to upgrade them to 2.5 and if so what are the steps to do that?
Thank you in advnace,
ars
For our Open Studio jobs, we added the necessary Java option to the call of the script, like:
myjob_run.sh -Dlog4j2.formatMsgNoLookups=true
Theoratically, that should pass the option on to java and you should be able to run your jobs safely without recompiling.
If I undrestood correctly, with Open Studio and standalone jobs, this approach would mitigate the theoretical risk where
1) an attacker has access to company internal network
2) is able to access the server that hosts the java applications
3) would then execute those java applications with malicious parameters, exploiting the vulnerability?
It sounds like this mitigation is necessary to be safe even with TOS, because say it is a trojan that scans the network for all jar files and tries to execute those with the malicious arguments: it does not matter if those are Talend jars or Websphere jars or whatever jars, the attacker just tries to exploit the underlying vulnerability.
It seems ElasticSearch is also affected, which is included in TAC. To mitigate the risk, in the %talend%/logserv/elasticsearch-7.x.x/config/jvm.options file add the options:
-Dlog4j2.formatMsgNoLookups=true
See https://www.elastic.co/guide/en/elasticsearch/reference/current/advanced-configuration.html#set-jvm-options
From what I understand, the issue is triggered if log4j renders a log message with a certain format. Thus, if your Talend calls a webservice that triggers Talend to log a message with a certain format, the attacker can execute a command on your machine.
So, theoratically, if the Talend Exchange would be compromised, all Studio clients could be in trouble. (As Talend stated, they made sure that wont happen)