Skip to main content
Announcements
See what Drew Clarke has to say about the Qlik Talend Cloud launch! READ THE BLOG
cancel
Showing results for 
Search instead for 
Did you mean: 
YPMAL
Contributor III
Contributor III

log 4j bug CVE-2021-44228- Urgently need to update log4j libraries for deployed jobs from talend 6.2.1

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 ?

79 Replies
paula11
Contributor III
Contributor III

@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)

MGreenslade1621434850
Contributor III
Contributor III

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?

reinierD
Contributor
Contributor

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.

Jean-François
Contributor
Contributor

Hi,

Could we have an expected date of delivery of the patch please?

Thanks a lot.

stucas
Contributor
Contributor

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:

  1. I have production code (my artifacts) that have been published with the "offending" libraries. These are now effectively redundant as all versions include this.
  2. My remote engines are potentially open to this attack
  3. Any existing development compiled from Studio will included this, even if I was able to mitigate this the CI/CD pipeline would recompile before publishing with the libraries that are included in the P2 image.

 

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!

MPT
Contributor III
Contributor III

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

 

  1. read a DB or file,
  2. do transformation and
  3. write to DB or file,

 

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,

StevanJovetic10
Contributor III
Contributor III

If I have deployed some jobs on a remote server before applying this flag, should i rebuild them and re-deploy them?

StevanJovetic10
Contributor III
Contributor III

Hi, do I need to rebuild and redeploy all my jobs that are running in a remote server after changing this setenv parameter?

reinierD
Contributor
Contributor

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.

StevanJovetic10
Contributor III
Contributor III

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.