Security vulnerability in log4j - KNIME software not affected

Resources Announcements
1

Summary

Several security vulnerability were identified in Apache Log4j 2, a library also present in current KNIME Analytics Platform installations (version 4.4 and 4.5). Details on the vulnerabilites are reported as CVE-2021-44228 and CVE-2021-45046 with more details and links on the Log4J security page.

Neither KNIME Server nor KNIME Analytics Platform are directly affected by these issues. KNIME Server application is not using Log4j. KNIME Analytics Platform uses an older version of Log4j (1.2.15) which is not affected by this issue. The only exception is a library used for processing PMML documents which does use Log4j 2 but is not susceptible to the published exploits. Read more details below.

In any case, we recommend adding the system property -Dlog4j2.formatMsgNoLookups=true at the bottom of the knime.ini. This is one of the official workarounds and safely prevents exploitation of the vulnerability.

Details

After careful review of the corresponding library, the reported vulnerability and the use within KNIME software, we came to the conclusion that the vulnerabilities can not be exploited in KNIME products.

Apache Log4j is a library to perform logging of application behavior. Though not used in the KNIME Server application (Tomcat), the library is distributed and used in versions 1 and 2 in KNIME Analytics Platform.

The above security problems are reported for version 2, which is present within KNIME Analytics Platform in a framework extension called Xmlbeans (org.apache.xmlbeans5_5.0.0.v202104291535/lib/log4j-core-2.14.0.jar). An exploit sends specially crafted requests to an affected service which includes them in log messages. This can then lead to loading and executing arbitrary code from remote locations. Since KNIME Analytics Platform is a local application, which does not listen for external requests, it is not susceptible to the issue.

When KNIME Analytics Platform is used as an executor for a KNIME Server, it is theoretically possible that an attacker invokes a workflow that processes provided data (e.g. a PMML model processed by the PMML Reader) through the XMLBeans library which then has to include parts of the sent file in a log message. However, this is rather difficult to construct (if at all, we did not find a way to do this on our own so far) and requires interaction of an authenticated user. Moreover the second vulnerability CVE-2021-45046 is only exploitable if the log format includes context-specific information. This is not the case for the logging configuration of KNIME Analytics Platform (see <runtime-workspace>/.metadata/knime/log4j3.xml).

An update of Log4j 2 to 2.17.1 will fix the issue and will be made available with the next regular bug fix release (KNIME Analytics Platform version 4.5.1 and 4.4.3).

KNIME Analytics Platform uses Log4J 1 for most of its logging. There are older security vulnerabilities reported against this version, CVE-2019-17571 and CVE-2020-9488, but none of them affect KNIME Analytics Platform because the affected parts (remote logging through SocketServer, JMS or SMTP Appender) are not in use.

25 Likes
3

Hi Thor,
I’ve just been updated by our security advisor that the recommended add in the system property has no use. See the link below. Do you have any idea when the bug fix release will take place? This will help us to exclude any risk related to this issue.

Kind regards,
Richard

Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046) | LunaSec

2 Likes
4

None of our products are affected by the new vulnerabilty CVE-2021-45046 because KNIME Analytics Platform does not log any context-specific data (unless you modified the log4j configuration yourself and included context-specific data - which does not make sense because there is none). You can verify this yourself by looking at /.metadata/knime/log4j3.xml. Therefore our previous statements still hold.

4 Likes
5

In concrete terms, this means that KNIME does not pose a threat to users through the log4j vulnerability.

Regards

2 Likes
6

Hi @thor
You mention explicitely KNIME Analytics Platform version 4.5.1 and 4.4.3 which are not affected. What about older versions of KNIME AP?
We are still on 4.3.4 is that unaffected as well?

1 Like
7

Versions older than 4.4 don’t use log4j 2 at all so they are not affected.

6 Likes
8

At my employer all systems are scanned for affected log4j components. Of course at my system it was found as part of KNIME.
Cyber Security teams have a really hard time these days. Every systems that triggers a warning is adding to their workload and slows detection of real critical issues.
Please don’t wait for the next regular bug fix.

3 Likes
9

Dear Team,

I agree with @KarstenG, really appreciate the communication above but security teams are using this detector, which even after having modified the .ini file returns knime as vulnerable.

GitHub Log4j detector

Also, updates to 2.15 or even 2.16 will not be sufficient as I understand they are now considered vulnerable.

I hear/read about cancelling the JndiLookup.class java class as a solution. Could it work?

Team, sorry I am a user and not a tech guy, I understand there might not be any actual exploitable vulnerability in Knime but until the scanner will highlight this vulnerability modern companies security teams would not be comfortable.

I don’t want to have to reinstall 4.3 to be honest but I might be forced to do so.

2 Likes
10

@thor Thanks for the post; from my understanding 2.15 is now known to be vulnerable. Do you have plans to pivot to 2.16 in the next release instead?

11

We will update to whatever version of log4j 2 is most recent in about a week.
But again, none of the vulnerabilities detected so far have an impact on KNIME software.

5 Likes
12

Hi,

what´s with external nodes which are installed? Is it possible that I download an (experimental) community extension and thereby download a node with an affected Log4j version?

Best regards

Alkaline

13

Yes, this is possible. We have already contacted the maintainer of community contributions which do use an affected version. But again, this doesn’t necessarily mean that the extension is actually vulnerable.

14

Hello. Just wondering if there’s any update on a new version with the log4j fixes in? Best regards.

1 Like
15

4.5.1 and 4.4.3 will likely be released tomorrow.

4 Likes
16

Thank you. I can see the changelog was updated yesterday for 4.5.1 but when I go to download the latest it is still downloading 4.5.0?

17

The released had to be delayed, it will likely be published this afternoon (European time).

1 Like
18

KNIME Analytics Platform 4.4.4 and 4.5.1 have been released. In both version log4j2 has been updated to 2.17.1.

2 Likes
19

Hi everyone, thanks a lot for the new version of KNIME 4.5.1 and KNIME Server 4.14.1 Unfortunately, I still find the old and EOL log4j version 1.2.15 in there. Did I download an old version?
It seems to me that other than stated only this xml beans plugin was updated to 2.17.1. I promised my security department KNIME will only use the most recent Log4j version from 4.5.1 on to be absolutely sure no old vulnerabilities are present anymore. I don’t know how to explain that now.

Best,
Lars

1 Like
20

We never intended to update log4j 1 since there are no known security problems unless you use a very uncommon custom configuration which we don’t do. Changing from log4j 1 to 2 is a much larger effort since all kinds of things have changed and there are also external libraries we currently use that also rely on Log4j 1. The chances of breaking something in a bug fix release along the way are way too high and are not justified given there are no relevant issues with log4 1.2.15. Replacing log4j 1 is on our list for the 4.6 release mid this year.

4 Likes