Geoserver - Replacing log4j 1.2.17 with 2.15.0?
Asked Answered
B

3

8

I have a geoserver on my webserver that uses log4j v 1.2.17 (log4j-1.2.17.jar).

I've downloaded the latest (safe?) version (2.15.0) from the log4j download site and checksummed the download.

I'm now confused as to which .jar I should try and use?

The version on my website is called log4j-1.2.17.jar, but the .jars in the download are all called something like e.g. log4j-web-2.15.0.jar

The geoserver's web server is jetty if that makes any difference.

What to do?

Bradley answered 12/12, 2021 at 16:59 Comment(3)
Log4j 1 is not affected by the vulnerability, see this comment. However, that library reached end of life in 2015, so it would be good to ask the maintainers nonetheless to switch to a newer logging framework.Plater
Don't ask for an upgrade. Sponsor it.Chengtu
The official GeoServer statement on this is here: geoserver.org/announcements/2021/12/13/logj4-rce-statement.htmlBashemath
G
12

There are significant changes in the way logging is done in the switch from log4j v1 (the one GeoServer uses) and log4j v2 (the one with the latest CVE). While GeoServer is immune to the RCE vulnerability mentioned in the question, there are still some small risks in using the old (and EOL) version we do use.

So as a temporary mitigation Andrea Aime has made a fork of the current log4j v1 trunk removing the network elements that might be abused by an attacker that has access to your GeoServer machine. See https://github.com/aaime/log4j for the tree you will need to clone and build. This will generate a new jar called log4j-1.2.17-norce.jar which you should replace log4j-1.2.17.jar with. You can now download that jar prebuilt from https://repo.osgeo.org/repository/geotools-releases/log4j/log4j/1.2.17/log4j-1.2.17-norce.jar

If you make use of GeoServer then you might like to contribute to the developers (or via the OSGEO foundation) to help support the work involved in reducing the technical debt of the project like updating the logging library.

Gilemette answered 13/12, 2021 at 14:0 Comment(8)
Interestingly you removed your previous awful answer. Thank you for providing a more useful one!Buatti
Things have calmed down a lot since yesterday, when all we had was people pressing for solutions with no supportGilemette
Thank you Ian and Andrea. I will try this and then accept the answer. I would also like to contribute to the developers :) Thanks againBradley
Log4j 1.x is EOL (as of Aug 2015) and has other listed CVE's and vulnerabilities (post-EOL) that will never be fixed.Burnish
@JoakimErdfelt - we know that, would you like to sponsor the upgrade work?Gilemette
I've tried this, and the geoserver is up, and has logged the usual restart warn :) Thanks again Ian and Andrea; I'll PM about sponsorship :)Bradley
After replacing log4j file with log4j-norce, I test my geoserver with log4shell.huntress.com and again gave me a security alert!Leviticus
That is a separate issue which is fixed 2.20.4Gilemette
A
4

There is a way to deactivate the log4j logging:

https://docs.geoserver.org/stable/en/user/configuration/logging.html

Forcing GeoServer to use an alternate logging redirection

[Updated] https://osgeo-org.atlassian.net/browse/GEOS-10333

Avicenna answered 13/12, 2021 at 13:56 Comment(0)
B
0

I've been looking into this myself for the same reasons and from I can gather you need to use log4j-1.2-api-2.15.0.jar based on the following read:

Perhaps the simplest way to convert to using Log4j 2 is to replace the log4j 1.x jar file with Log4j 2's log4j-1.2-api.jar.

source

I would like to point out that this shouldn't be the accepted answer but I wanted to give an answer for those who are trying to grasp the situation.

[Edit]

It would seem that log4j-1.2-api-2.15.0.jar is not enough. It helps with migrating Geoserver to the newer log4j version whilst still using the previous main package but it fails to reference to the newer version. As such I also added log4j-api-2.15.0.jar to the mix to complete the pathing.

After this it seems to work again and the version has been updated. I could validate this by using the api of Geoserver (/geoserver/rest/about/manifest.xml) specifically. If you search for log4j before upgrading you'll see 1.2.17 and afterwards 2.15.

Buatti answered 13/12, 2021 at 12:40 Comment(4)
Did you try that? GeoServer should not even start due to differences in the API (the GeoServer GUI based logging level switcher uses the Log4J API directly, and that part runs also straight on startup...)Chengtu
@AndreaAime Yes I did try though I failed to notice at first that the log was actually being made. GeoServer did in fact boot up but I was unable to write a log via Log4j. So sadly it wouldn't be a viable solution if you plan on using Log4j. If you weren't using it then you could always see this as a possible solution.Buatti
Note log4j2 v2.15.0 has other vulnerabilities identified in CVE-2021-45046, use version 2.16.0Burnish
I just noticed so thanks for the update though my original approach probably won't be of much help anyway. @AndreaAime I noticed what the problem could be on my end. Though GeoServer did in fact start up, the logging did not. This was probably due to the DEFAULT_LOGGING.properties using a RollingFileAppender, which doesn't exist in the 2.15 (and probably 2.16) main package. If it were, then I'd assume it would work without a hitch.Buatti

© 2022 - 2024 — McMap. All rights reserved.