[CVE-2021-44228] Log4j vulnerability

[mbrunger]

Hi, what is the impact of the log4j vulnerability on GeoNetwork. Are you planning to release a patch?

[jahow]

Hi, this is a good question. Our first analysis showed that log4j2 is present in the GeoNetwork classpath, both in versions 3 and 4, but it is apparently not used anywhere.

At Camptocamp we are still hard at work investigating if parts of the application are exposed to this vulnerability. Any effort in that direction is welcome.

In case parts of the application are indeed exposed, hotfixes will have to be produced on all recent branches (4.0, 3.12, 3.10 and maybe earlier versions as well).

[jahow]

Actually, thanks to @josegar74 the version of log4j2 was upgraded and the backports done on friday, see: #6075

@josegar74 could you please confirm that everything was done to be safe from this vunlerability? Thanks!

[jahow]

As for users of GeoNetwork 4, some versions of ElasticSearch use a version of log4j2 that is exposed to the vulnerability; please refer to this announcement for more information. Note that ElasticSearch is on the safe side anyway, so what's described there is mainly for additional safety.

Also this states that Kibana is not affected by the vulnerability.

Last thing is to make sure that the recommandations cited in the announcement are applied to the embedded ElasticSearch instance in the es module of GeoNetwork (which is version 7.11.1).

[mbrunger]

I saw this page from the GN installation guide where it is written that Log4j is used for logging in GeoNetwork. The version is not mentioned, but Log4j v1.x might be just as vulnerable, it is only no longer supported.

[josegar74]

Hi

A patch for 3.10.x has been released (3.10.10 https://sourceforge.net/projects/geonetwork/files/GeoNetwork_opensource/v3.10.10/), tomorrow I'll check to make a release for 3.12.

[KoalaGeo]

Great work @josegar74!

I've made a PR to update the docker repo for 3.10.10 - geonetwork/docker-geonetwork#75

What's the lead time between Sourceforge & dockerhub? I can't see a GitHub action setup - is it manual?

[jahow]

I saw this page from the GN installation guide where it is written that Log4j is used for logging in GeoNetwork. The version is not mentioned, but Log4j v1.x might be just as vulnerable, it is only no longer supported.

This is true but at least log4j v1 is not exposed to this specific vulnerability (which relies on a feature not present in versions before 2). Migrating to a more recent logger is indeed a task long overdue for GeoNetwork.

[juanluisrp]

I've created geonetwork/docker-geonetwork#76 (I didn't see your PR @KoalaGeo).

What's the lead time between Sourceforge & dockerhub? I can't see a GitHub action setup - is it manual?

I've created docker-library/official-images#11490. Now Docker official images team has to review it and merge. I think they work with US office time. When merged the image is automatically built and published in https://hub.docker.com/_/geonetwork

[fnicollet]

Hello,

We are using Geonetwork 3.10.4. It seems to use log4j 2.7:

Mitigating the issue using a java parameter (-Dlog4j.formatMsgNoLookups=true) is apparently only available in log4j 2.10+, so i guess it has no effect on this version Geonetwork.

I read online that:

For Log4j 2.7 or higher: specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.

I tried changing WEB-INF/classes/log4j.xml and changing:

<param name="ConversionPattern" value="%d{ISO8601} %-5p [%c] - %m%n"/>

to

<param name="ConversionPattern" value="%d{ISO8601} %-5p [%c] - %m{nolookups}%n"/>

Which seem to change the output log (so log4j is used @jahow ?) but seems to be appended:

2021-12-13 13:47:40,939 WARN  [geonetwork.schemamanager] - WARNING: schema-substitutions.xml has wiped out XSD substitution list for gml:VerticalCS{nolookups}
2021-12-13 13:47:40,941 WARN  [geonetwork.schemamanager] - WARNING: schema-substitutions.xml has wiped out XSD substitution list for gml:CoordinateSystemAxis{nolookups}

So I am not sure if it really mitigates the issue. Anyone else is try to hotfix this ?

Thanks!
Fabien

[juanluisrp]

Which seem to change the output log (so log4j is used @jahow ?) but seems to be appended

That looks like an output produced by log4j-1.2.17

[fnicollet]

@juanluisrp that makes sense! So both log4j 1.x and log4j 2.x are loaded in the classpath but only v1.x is used. Then this version is not subject to vulnerability, that's good news :)

[juanluisrp]

We aren't sure if any dependency is using it internally, so I'd recommend to be cautious with such statement.

In the meantime you can remove the JndiLookup.class from the 2.7 jar running

zip -d ${TOMCAT_HOME}/webapps/geonetwork/WEB-INF/lib/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class

and restarting your server. If you have deployed the app using the WAR you will also need to replace the WEB-INF/lib/log4j-core-2.* file with the patched one and repackage the WAR.

[pmauduit]

The Log4j configurations provided in the webapp are targetting log4j1, which is also still present in the classpath. I tried removing the log4j2 dependency and GN still compiles fine, my assumption is that even if log4j2 is present, the code is never called nor used.

Checking dependencies using mvn dependency:tree, it looks like it is needed by the elasticsearch client though:

[INFO] +- org.elasticsearch.client:elasticsearch-rest-high-level-client:jar:7.11.1:compile
[INFO] |  +- org.elasticsearch:elasticsearch:jar:7.11.1:compile
[INFO] |  |  +- org.elasticsearch:elasticsearch-core:jar:7.11.1:compile
[INFO] |  |  +- org.elasticsearch:elasticsearch-secure-sm:jar:7.11.1:compile
[INFO] |  |  +- org.elasticsearch:elasticsearch-x-content:jar:7.11.1:compile
[INFO] |  |  |  +- org.yaml:snakeyaml:jar:1.26:compile
[INFO] |  |  |  +- com.fasterxml.jackson.dataformat:jackson-dataformat-smile:jar:2.10.4:compile
[INFO] |  |  |  +- com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.10.4:compile
[INFO] |  |  |  \- com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:jar:2.10.4:compile
[INFO] |  |  +- org.elasticsearch:elasticsearch-geo:jar:7.11.1:compile
[INFO] |  |  +- org.apache.lucene:lucene-core:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-analyzers-common:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-backward-codecs:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-grouping:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-highlighter:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-join:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-memory:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-misc:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-queries:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-queryparser:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-sandbox:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-spatial-extras:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-spatial3d:jar:8.7.0:compile
[INFO] |  |  +- org.apache.lucene:lucene-suggest:jar:8.7.0:compile
[INFO] |  |  +- org.elasticsearch:elasticsearch-cli:jar:7.11.1:compile
[INFO] |  |  |  \- net.sf.jopt-simple:jopt-simple:jar:5.0.2:compile
[INFO] |  |  +- com.carrotsearch:hppc:jar:0.8.1:compile
[INFO] |  |  +- joda-time:joda-time:jar:2.10.4:compile
[INFO] |  |  +- com.tdunning:t-digest:jar:3.2:compile
[INFO] |  |  +- org.hdrhistogram:HdrHistogram:jar:2.1.9:compile
[INFO] |  |  +- org.apache.logging.log4j:log4j-api:jar:2.11.1:compile
[...]

Main question is: is it possible to trick the ES rest client so that something is logged ?

[archaeogeek]

Can anyone comment on whether the patch for 3.10.x and 3.12.x (eg #6075) will also be applicable for earlier versions? I have a site running 3.4.x that I am currently trying to upgrade but I may need to patch it until the upgrade is complete.

[jahow]

Can anyone comment on whether the patch for 3.10.x and 3.12.x (eg #6075) will also be applicable for earlier versions? I have a site running 3.4.x that I am currently trying to upgrade but I may need to patch it until the upgrade is complete.

If there is an ongoing upgrade then instead of relying on an official release you can maybe try to remove the log4j2 jars from the war file.

For those wondering, log4j2 was introduced in v3.4, see commit: 69be7af

Any version before that is supposedly safe