[BlueOnyx:25244] Re: log4j java vulnerability

Michael Stauber mstauber at blueonyx.it
Sat Dec 11 10:23:24 -05 2021


Hi Larry,

> What all blueonyx is affected by this vulnerability?
> and what can we do short term to mitigate it?

We're good.

BlueOnyx 5210R doesn't ship with "log4j", as we ditched the Java stuff.

On BlueOnyx 5209R we do have the "log4j" RPM installed. But unless you
have Tomcat enabled you're not at risk.

I then checked what actually required the presence of "log4j" on 5209R:

---------------------------------------------------------------
[root at 5209r ~]# rpm -q --whatrequires log4j
avalon-framework-4.3-10.el7.noarch

[root at 5209r ~]# rpm -q --whatrequires avalon-framework
avalon-logkit-2.1-14.el7.noarch

[root at 5209r ~]# rpm -q --whatrequires avalon-logkit
avalon-framework-4.3-10.el7.noarch

[root at 5209r ~]# rpm -q --whatrequires avalon-logkit avalon-framework
avalon-framework-4.3-10.el7.noarch
avalon-logkit-2.1-14.el7.noarch

[root at 5209r ~]# rpm -e log4j avalon-logkit avalon-framework
error: Failed dependencies:
        mvn(log4j:log4j) is needed by (installed)
apache-commons-logging-1.1.2-7.el7.noarch
        mvn(logkit:logkit) is needed by (installed)
apache-commons-logging-1.1.2-7.el7.noarch
        mvn(avalon-framework:avalon-framework-api) is needed by
(installed) apache-commons-logging-1.1.2-7.el7.noarch

[root at 5209r ~]# rpm -q --whatrequires apache-commons-logging
avalon-framework-4.3-10.el7.noarch
jakarta-commons-httpclient-3.1-16.el7_0.noarch
tomcat-7.0.76-16.el7_9.noarch
---------------------------------------------------------------

Means: Around several corners it's a dependency of Tomcat 7, which isn't
surprising.

Next I checked the RedHat advisory pages for CVE-2021-44228:

https://access.redhat.com/security/cve/CVE-2021-44228

The state this for mitigation:

---------------------------------------------------------------
Mitigation

There are two possible mitigations for this flaw in versions from 2.10
to 2.14.1:
- Set the system property log4j2.formatMsgNoLookups to true, or
- Remove the JndiLookup class from the classpath. For example:

zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class
---------------------------------------------------------------

Also, for Red Hat Enterprise Linux 6/7/8 they state: Not affected

Which isn't surprising, as the issue only pops up if there is an
application that actively uses log4j. Which there usually isn't out of
the box. Unless you have (for example) SOLR, JBoss, OpenShift, CodeReady
Studio or something similar installed that uses the JndiLookup Java class.

In our case (on 5209R) we ship with Tomcat disabled by default and
Tomcat would be the closest thing to even remotely make use of "log4j" -
provided the end user installs an app or uses a Java Class that makes
use of "log4j" via JndiLookup. Just Tomcat being active and running
doesn't make a 5209R vulnerable. There needs to be some Java code
present that provides an attack surface.

So all in all: If you're on a 5209R and are worried, then turn off
Tomcat until you've had a chance to review if your Java stuff makes use
of JndiLookup.

If you have Tomcat disabled on 5209R, then you're good anyway.

-- 
With best regards

Michael Stauber



More information about the Blueonyx mailing list