Apache Log4J Vulnerability - CVE-2021-44228

[Kevin.Herron]

On December 9th, 2021, a new vulnerability was reported (CVE-2021-44228) against a common Java logging library, “log4j”. This vulnerability makes affected systems susceptible to having remote attackers be able to run malicious programs on said systems. This is also known as an RCE, or Remote Code Execution attack.

Inductive Automation has conducted a full audit of Ignition’s direct and transitive dependencies to confirm that log4j is not used or included in any supported or unsupported release of Ignition, and as such it is not vulnerable to the RCE outlined in CVE-2021-44228. This includes LTS versions 7.9 and 8.1, as well as all past and non-LTS versions. While Ignition versions 7.8 and prior did use log4j for its logging backend, the version used (1.2.x) is not affected.

No action is required by any Ignition user on any version of Ignition, LTS or not, to mitigate the effects of CVE-2021-44228.

Regarding CVE-2021-44228 - Log4j RCE 0-day

[guanghui]

Great! But is it possible to use log4j in third-party modules? if yes , will that be unsafe?

[Kevin.Herron]

Log4j vulnerability and third-party modules

We can talk to our strategic partners, but all the modules you listed are ours and they do not include log4j. The whole idea of a 3rd party bringing log4j as a dependency is very unusual - the logging backend is provided by the Ignition platform and anybody who knows what they are doing would log using the SLF4J logging API and not introduce a parallel logging backend, which would result in an additional set of logs/files being generated.

[pturmel]

@guanghui

use log4j in third-party

Module install files are just zip files. You can just open them and look.

[justin.brzozoski]

Over on their forum, CirrusLink confirmed that their Ignition modules and Chariot MQTT broker are safe.

Log4j vulnerability (log4shell)

[Kyle_Chase]

Modules from Kymera Systems are also not affected by the Log4J vulnerability.

[pturmel]

So too with all of Automation Professionals’ modules.

[richardNZ15]

I just received a report from a customer that use Crowdstrike for vulnerability management, and they provided the following details in their report:

Here are the details of Log4j that have been detected -

Version: log4j-over-slf4j-1.7.26.

It looks like the log4j library is detected here:
lib/core/common/log4j-over-slf4j-1.7.26.jar

This is on Ignition 8.1.7.

Sounds like the vulnerability is only for log4j versions 2.0.1 to 2.15.0, which would make this version used by Ignition ok?

[Kevin.Herron]

False positive.

Log4J on Linux & Windows

Yes, should be good to go. The last version of Ignition that used log4j was 7.8, and it used something like log4j version 1.2.x, which isn’t affected by this CVE. Those who snoop around may find an artifact called log4j-over-slf4j, but this just a bridge that let us move from log4j to slf4j/logback without modifying every single file that had used a log4j logger.

[dion.botha]

I was asked about this by our IT security department a few days after the venerability was discovered. Just wanted to give a shout out to IA, it was super easy to find and share this post which alleviated immediate concern and probably installed greater approval in the Ignition platform from their perspective!