GeoServer Blog

Jiffle and GeoTools RCE vulnerabilities

A few critical vulnerabilities have been located in the GeoServer ecosystem that allow Remote Code Execution. This article describes the vulnerabilities, their mitigation, and links to patched versions of the various projects involved.

All the issues described in this post have been patched in:

The rest of the POST describes the issues and their mitigation.

RCE in Jiffle

The Jiffle map algebra language, provided by jai-ext, allows efficiently execute map algebra over large images. A vulnerability has been recently found in Jiffle, that allows a Code Injection to be performed by properly crafting a Jiffle invocation.

In the case of GeoServer, the injection can be performed from a remote request.

Assessment

GeoTools includes the Jiffle language as part of the gt-process-raster-<version> module, applications using it should check whether it’s possible to provide a Jiffle script from remote, and if so, upgrade or remove the functionality (see also the GeoServer mitigation, below).

Stand-alone GeoWebCache is not affected, as it does not include Jiffle support.

The issue is of particular interest for GeoServer users, as GeoServer embeds Jiffle in the base WAR package. Jiffle is available as a OGC function, for usage in SLD rendering transformations.

This allows for a Remote Code Execution in properly crafted OGC requests, as well as from the administration console, when editing SLD files.

Mitigations

In case you cannot upgrade at once, then the following mitigation is strongly recommended:

  1. Stop GeoServer
  2. Open the war file, get into WEB-INF/lib and remove the janino-<version>.jar
  3. Restart GeoServer.

This effectively removes the Jiffle ability to compile scripts in Java code, from any of the potential attack vectors (Janino is the library used to turn the Java code generated from the Jiffle script, into executable bytecode).

GeoServer should still work properly after the removal, but any attempt to use Jiffle will result in an exception.

Resolution

Issue:

RCE in JNDI lookups

The GeoTools data stores, as well as the disk quota mechanism of GeoWebCache, and the JDBC user/role providers for GeoServer can all fetch connection pools from JNDI.

A properly crafted JNDI source name can cause uncontrolled deserialization of classes and eventually a Remote Code Execution, in a way similar to Log4Shell. However, unlike Log4Shell, it requires the administrator to enter these strings.

Mitigations

In terms of mitigation, GeoTools users should make sure the JNDI strings given to stores cannot be provided from remote, or external parties, without validation.

Stand-alone GeoWebCache users must now allow external or remote users to change the disk quota XML configuration files, guarding both local file system access, and the REST configuration API. The REST API can only be accessed authenticating as administrator, good practices in this regard involve:

  • Disallowing remote access to the “/rest” endpoint in a GeoWebCache installation
  • Rotating the administrator passwords.

GeoServer is affected though the Web administration interface and the REST configuration API, both of which require an administrator login to be used in order to setup JNDI connection strings. In order to mitigate the issue:

  • Disallow remote access to the “/rest” and “/web” endpoints in a GeoServer installation.
  • Change/rotate the administrator passwords.

Resolution

The following issues have been resolved, and patched releases are available.

Issue:

Thanks to Andrea Aime (GeoSolutions) for working so hard on this fix.

SpringShell

Both GeoServer and GeoWebCache use Spring MVC, for REST API controllers in both projects, and for the OGC API, GSR and taskmanager community modules, in GeoServer. The projects are commonly deployed as WAR files in Tomcat, with a fair amount of deploys using Java 11 and above.

This sets up both projects for exploit via the SpringShell vulnerability. however we looked, and could not find an actual attack vector.

This release train updates to newer a version of spring-framework that patched this potential issue.

Mitigations

For those that cannot upgrade, the recommended mitigations are:

  • Run GeoServer and GeoWebCache on Java 8 instead, which is not vulnerable to the issue.
  • Upgrade Tomcat to the releases that patched the attack vector, either 9.0.62 or 8.5.78 (don’t try to use Tomcat 10.x, GeoServer cannot run on it due to incompatible J2EE libraries).
  • For extra security, limit access to the REST API, and remove community modules providing new service endpoints (OGC API, GSR, taskmanager).

Resolution

Although GeoServer assessment did not identify any issue we have now updated the the spring framework library.

Issue:

  • GEOS-10445 Upgrade springframework from 5.1.20.RELEASE to 5.2.20.RELEASE

Thanks to Gabriel Roldan (camptocamp) for troubleshooting and performing this spring-framework update.

Read More

GeoServer 2.20.4 Released

GeoServer 2.20.4 release is now available with downloads (bin, war, windows), along with docs and extensions.

This is a stable release of the 2.20.x series recommended for production systems. This release was made in conjunction with GeoTools 26.4.

Thanks to everyone who contributed, and to Andrea Aime (GeoSolutions) and Jody Garnett (GeoCat) for making this release.

Security Considerations

This release includes several security enhancements and is a recommended upgrade for production systems.

This release includes two improvements addressing Jiffle and GeoTools RCE vulnerabilities:

This release also includes:

  • GEOS-10445 Upgrade springframework from 5.1.20.RELEASE to 5.2.20.RELEASE

    Although GeoServer assessment did not identify any issue we have now updated the the spring framework library.

2024-06-30 Update: The following mitigation has been provided:

  • CVE-2024-36401 Remote Code Execution (RCE) vulnerability in evaluating property name expressions (Critical)

    geoserver-2.20.4-patches (replacing gt-app-schema, gt-complex and gt-xsd-core jars) has been provided by Andrea (GeoSolutions)

See project security policy for more information on how security vulnerabilities are managed.

Add Styles support to LayerGroup

Allows layer group (layer mode SINGLE or OPAQUE) list alternate styles in addition to the default one. Each alternate style is defined by a named configuration of layers and styles providing a unique visual representation.

  • GEOS-10252 Add Styles support to LayerGroup
  • GEOS-10274 Geofence follow up LayerGroup Style addition

For more information see GSIP-205 Add Styles support to LayerGroup proposa.

Improvements and Fixes

Improvements:

  • GEOS-10434 Externalized GeoServer environment properties

  • GEOS-10427 Improve access check in ImportProcess

  • GEOS-10409 Improve deletion of WPS Execute input temp files

Fixes:

  • GEOS-10437 Breaking SLD 1.1 style by REST upload

  • GEOS-10419 NullPointerException from GeoServerOAuthAuthenticationFilter

  • GEOS-10418 Bad request sent to GeoFence when matching roles only

  • GEOS-10401 WPS GetExecutionResult doesn’t validate the mimetype parameter

  • GEOS-10400 Disabling WMS dynamic styling does not affect GetLegendGraphic requests

  • GEOS-10393 WFS-T deletes the wrong features (and further BatchManager issues)

  • GEOS-9978 WMS vendor parameter CLIP - ignores TIME/CQL_FILTER and other parameters when using with ImageMosaic

Tasks:

  • GEOS-10445 Upgrade springframework from 5.1.20.RELEASE to 5.2.20.RELEASE

  • GEOS-10303 Upgrade to jackson 2.13.2

For more information see 2.20.4 release notes.

About GeoServer 2.20

Additional information on GeoServer 2.20 series:

Release notes: ( 2.20.4 | 2.20.3 | 2.20.2 | 2.20.1 | 2.20.0 | 2.20-RC )

Read More

GeoServer 2.19.6 Released

GeoServer 2.19.6 release is now available with downloads (bin, war, windows), along with docs and extensions.

This is an extra maintenance release of the 2.19.x series recommended for production systems. This release was made in conjunction with GeoTools 25.6.

Thanks to everyone who contributed, and to Andrea Aime (GeoSolutions) for making this release.

Security Considerations

This release includes several security enhancements and is a recommended upgrade for production systems.

This release includes two improvements addressing Jiffle and GeoTools RCE vulnerabilities:

This release also includes:

  • GEOS-10445 Upgrade springframework from 5.1.20.RELEASE to 5.2.20.RELEASE

    Although GeoServer assessment did not identify any issue we have now updated the the spring framework library.

Improvements and Fixes

Fixes:

  • GEOS-10437 Breaking SLD 1.1 style by REST upload

  • GEOS-10336 INSPIRE failure: version not propagated in GetCapabilities LegendURL

  • GEOS-9978 WMS vendor parameter CLIP - ignores TIME/CQL_FILTER and other parameters when using with ImageMosaic

Tasks:

For more information see 2.19.6 release notes.

About GeoServer 2.19

Additional information on GeoServer 2.19 series:

Release notes ( 2.19.6 | 2.19.5 | 2.19.4 | 2.19.3 | 2.19.2 | 2.19.1 | 2.19.0 | 2.19-RC )

Read More

GeoServer 2.18.6 Released

GeoServer 2.18.6 release is now available with downloads (bin, war, windows), along with docs and extensions.

This is an extra maintenance release of the 2.18.x series recommended for production systems that have not yet upgraded to 2.19. This release was made in conjunction with GeoTools 24.6.

Thanks to everyone who contributed, and to Andrea Aime (GeoSolutions) and Jody Garnett (GeoCat) for making this release.

Security Considerations

This release includes security enhancements and is a recommended upgrade for production systems.

This release includes two improvements addressing Jiffle and GeoTools RCE vulnerabilities:

This release also includes:

  • GEOS-10445 Upgrade Spring Framework from 5.1.20.RELEASE to 5.2.20.RELEASE

    Although GeoServer assessment did not identify any issue we have now updated the the spring framework library.

Improvements and Fixes

  • GEOS-10437 Breaking SLD 1.1 style by REST upload

  • GEOS-10249 GWC produce NPE when it comes to race condition

  • GEOS-10215 Layers nested inside a group maintain their prefix even in workspace specific services

  • GEOS-10213 WMS requests fail on LayerGroup default style names, when used in GetMap/GetFeatureInfo/GetLegendGraphics

  • GEOS-10200 GetLegendGraphic can fail if SCALE removes all rules

  • GEOS-10321 WCS 2.0 might fail to return coverages whose native BBOX goes slighly outside of the dateline

  • GEOS-10194 Improve importer LOGGING

  • GEOS-10335 Update GeoServer to a log4j version that does not support RCEs

For more information see 2.18.6 release notes.

About GeoServer 2.18

Additional information on GeoServer 2.18 series:

Release Notes ( 2.18.6 | 2.18.5 | 2.18.4 | 2.18.3 | 2.18.2 | 2.18.1 | 2.18.0 | 2.18-RC )

Read More

Spring4Shell RCE vulnerability

A vulnerability has located in the Spring Framework ecosystem that allow Remote Code Execution. This article describes the vulnerability, assessment, mitigation, and links to patched versions of the various projects involved.

Please do not contact us asking about this vulnerability unless you are reporting an actual demonstration of the problem in a GeoServer installation or are offering to assist in the upgrade process with developer time or money.

If you wish to report a security vulnerability, see instructions on responsible reporting. We also welcome your direct financial support.

Spring4Shell (CVE-2022-22965)

A recently discovered vulnerability in the Spring (CVE-2022-22965) has been reported as affecting systems running Java 9+.

Note systems using Java 8 are not thought to be vulnerable at this time.

Assessment

Both GeoServer and GeoWebCache use Spring MVC, for REST API controllers in both projects, and for the OGC API, GSR and taskmanager community modules, in GeoServer. The projects are commonly deployed as WAR files in Tomcat, with a fair amount of deploys using Java 11 and above.

This sets up both projects for exploit on the SpringShell vulnerability.

We looked , and could not find an actual attack vector yet, but have scheduled a release that contains a spring-framework update that patches the potential issue.

Mitigation

For those that cannot upgrade, the recommended mitigations are:

  • Run GeoServer and GeoWebCache on Java 8 instead, which is not vulnerable to the issue.
  • Upgrade Tomcat to the releases that patched the attack vector, either 9.0.62 or 8.5.78 (don’t try to use Tomcat 10.x, GeoServer cannot run on it due to incompatible J2EE libraries).
  • For extra security, limit access to the REST API, and remove community modules providing new service endpoints (OGC API, GSR, taskmanager).

Resolution

We are working on upgrading to a patched version of the spring framework library and will post an update when that work is complete.

Issue:

  • GEOS-10445 Upgrade springframework from 5.1.20.RELEASE to 5.2.20.RELEASE

Patched releases:

Thanks to everyone who reported this issue, Andrea Aime (GeoSolutions) for initial assessment, and to Gabriel Roldan (camptocamp) for troubleshooting and performing this spring-framework update.

Read More