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 ?
@Xiaodi Shi
Thank for this helpfull description!!!
In our installation we have set the setting for TAC in setenv.bat (The setenv.sh does not exist in our installation)
Many of our pom.xml files still show <artifactId>log4j</artifactId><version>1.2.17</version> despite making sure the Project Settings in TOS 7.4 have the log4j version 2 selected but the 'enable log4j on components' unchecked.
Is there a way to get the pom.xml files to change from 1.2.17 to 2.12? Do we need to open every single job in a project?
This should be in the patch we are all waiting for. In the meantime, there are a bunch of workarounds mentioned in this thread, depending on which product(s) you are using.
Hi,
Could we have an expected date of delivery of the patch please?
Thanks a lot.
Still awaiting on a reply from Talend.
We run a number of remote engines with a CI/CD pipeline pushing artifacts to the TMC.
Looking at our version of Studio (and V8.0.1) these products are using log4j < 2.15 so are open to the vulnerability. The issue as I see are a number of issues that need to be addressed:
The response from Talend in asking how we might mitigate this risk was:
"Our team has been made aware of this CVE and the risks associated with it. Right now, our team is working to identify and mitigate all portions of Talend that fall under the scope of this issue. At this time, our team is still working on this issue, and verifying both a short-term and long-term solution that can mitigate the risk, and customers can use.
We will be able to provide your team with an update in the coming days on the status of this bug/risk, and the next steps.
Regarding your questions, the change mentioned is not advised by R&D as they are working on finding a solution as mentioned above"
Wish this was more helpful - but our security people are seeing attacks using this vector - and although we have put actions in place on our WAF etc, this is still a cause for concern.
/TALEND BUMP!
I understand that we're partly theorising, but in that spirit I take this a bit futher:
if a company uses Open Studio DI and schedules and runs locally deployed java applications which do ETL processes (by comparison they could be running a bunch of Powershell scripts on the domain controller) and those java jobs
the likelihood of one of those known external systems to return a malicious exception message that exploits this vulnerability feels low. "Never say never," but still. Mind you I'm not speaking against mitigations and updates, I'm just trying to identify how critical it is for Open Studio users to start adding JVM arguments to all those jars that are deployed to the file server when there are most likely other critical systems to fix too,
If I have deployed some jobs on a remote server before applying this flag, should i rebuild them and re-deploy them?
Hi, do I need to rebuild and redeploy all my jobs that are running in a remote server after changing this setenv parameter?
No you dont. You will have to rebuild your jobs, once Talend provides a patch for Studio that generates code with a dependency on the new log4j-core library.
Thank you 🙂 so, adding this environment variable to the .ini file should work for now even if i dont rebuild and redeploy my jobs?
The Talend environment in which i develop is my phisical machine, but i have deployed these jobs on a remote server.
Again, thank you for the clarification.